Wouldn''t it be more reasonable to have /dev/mem represent machine addresses only outside of the range of physical memory assigned to a VM, and physical addresses inside this range? That way, more consistent behavior should be achieved to native systems. What I''m seeing is that accesses to /dev/mem offset 0x100000 get a failure in __direct_remap_pfn_range() (including, if debugging is turned on, two log messages from the hypervisor). If these accesses went to kernel memory instead, consumers of this interface would get exactly what they get on a native OS. Further I would think that such map attempts shouldn''t even make it to the hypervisor, thus avoiding the log messages (which I started looking into only because I thought they might indicate a latent bug of some sort). This would, however, require knowledge in the kernel which addresses (or address ranges) represent physical memory (rather than potential I/O memory regions). Finally, while following the involved code paths, I noted a check that is made in __ioremap, by calling is_local_lowmem(). It would seem to me that calling this function just for the first address is insufficient - the range specified may begin in non-lowmem but end in lowmem. Or it may begin in lowmem and end in non-lowmem, in which case I would think that virt_to_page() wouldn''t work correctly anymore (permitting, say, an erroneous dd command issued by root to result in an oops or maybe worse things). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 24 Jan 2006, at 16:26, Jan Beulich wrote:> Wouldn''t it be more reasonable to have /dev/mem represent machine > addresses only outside of the range of physical memory > assigned to a VM, and physical addresses inside this range? That way, > more consistent behavior should be achieved to > native systems. > > What I''m seeing is that accesses to /dev/mem offset 0x100000 get a > failure in __direct_remap_pfn_range() (including, if > debugging is turned on, two log messages from the hypervisor). If > these accesses went to kernel memory instead, > consumers of this interface would get exactly what they get on a > native OS.Does anyone sane peek /dev/mem to get at kernel code/data? I doubt it.> Further I would think that such map attempts shouldn''t even make it to > the hypervisor, thus avoiding the log messages > (which I started looking into only because I thought they might > indicate a latent bug of some sort). This would, > however, require knowledge in the kernel which addresses (or address > ranges) represent physical memory (rather than > potential I/O memory regions).Non-debug Xen builds don;t print those messages so won''t scare users.> Finally, while following the involved code paths, I noted a check that > is made in __ioremap, by calling > is_local_lowmem(). It would seem to me that calling this function just > for the first address is insufficient - the range > specified may begin in non-lowmem but end in lowmem. Or it may begin > in lowmem and end in non-lowmem, in which case I > would think that virt_to_page() wouldn''t work correctly anymore > (permitting, say, an erroneous dd command issued by root > to result in an oops or maybe worse things).It''s assumed people using those interfaces know what they''re doing. How can a ''dd'' end up in __ioremap() anyway? -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> > What I''m seeing is that accesses to /dev/mem offset 0x100000 get a > > failure in __direct_remap_pfn_range() (including, if > > debugging is turned on, two log messages from the hypervisor). If > > these accesses went to kernel memory instead, > > consumers of this interface would get exactly what they get on a > > native OS. > > Does anyone sane peek /dev/mem to get at kernel code/data? I doubt it.In the old days of 2.4 (and some of 2.6???), /dev/mem would only map memory with the reserved bit set, because the only users watned device memory, not real RAM (and because implementing full functionality upset memory management in a way I''m not too clear on now...). As a result peeking kernel code / data wasn''t even possible on native Linux in the recent past... Cheers, Mark> > Further I would think that such map attempts shouldn''t even make it to > > the hypervisor, thus avoiding the log messages > > (which I started looking into only because I thought they might > > indicate a latent bug of some sort). This would, > > however, require knowledge in the kernel which addresses (or address > > ranges) represent physical memory (rather than > > potential I/O memory regions). > > Non-debug Xen builds don;t print those messages so won''t scare users. > > > Finally, while following the involved code paths, I noted a check that > > is made in __ioremap, by calling > > is_local_lowmem(). It would seem to me that calling this function just > > for the first address is insufficient - the range > > specified may begin in non-lowmem but end in lowmem. Or it may begin > > in lowmem and end in non-lowmem, in which case I > > would think that virt_to_page() wouldn''t work correctly anymore > > (permitting, say, an erroneous dd command issued by root > > to result in an oops or maybe worse things). > > It''s assumed people using those interfaces know what they''re doing. How > can a ''dd'' end up in __ioremap() anyway? > > -- Keir > > > _______________________________________________ > Xen-devel mailing list > Xein-devel@lists.xensource.com > http://lists.xensource.com/xen-devel-- Dave: Just a question. What use is a unicyle with no seat? And no pedals! Mark: To answer a question with a question: What use is a skateboard? Dave: Skateboards have wheels. Mark: My wheel has a wheel! _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>> Finally, while following the involved code paths, I noted a check that >> is made in __ioremap, by calling >> is_local_lowmem(). It would seem to me that calling this function just >> for the first address is insufficient - the range >> specified may begin in non-lowmem but end in lowmem. Or it may begin >> in lowmem and end in non-lowmem, in which case I >> would think that virt_to_page() wouldn''t work correctly anymore >> (permitting, say, an erroneous dd command issued by root >> to result in an oops or maybe worse things). > >It''s assumed people using those interfaces know what they''re doing. How >can a ''dd'' end up in __ioremap() anyway?/dev/mem''s read/write handlers call ioremap... Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 25 Jan 2006, at 08:24, Jan Beulich wrote:>> It''s assumed people using those interfaces know what they''re doing. >> How >> can a ''dd'' end up in __ioremap() anyway? > > /dev/mem''s read/write handlers call ioremap...A user who dd''s /dev/mem deserves all he gets! -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel