Re: reading /dev/mem panics a domU
On Fri, Jan 13, 2012 at 06:04:15AM +0100, Emmanuel Dreyfus wrote: Hi I just discovered the oddity below, on a netbsd-5 domU. Is there a reason for not calling that a bug? Does it happens only at mine? It is a bug; please send-pr. I can reproduce it with a HEAD kernel too. This seems to be i386-specific; a amd64 domU doens't crash. -- Manuel Bouyer bou...@antioche.eu.org NetBSD: 26 ans d'experience feront toujours la difference --
Re: reading /dev/mem panics a domU
On Fri, Jan 13, 2012 at 09:53:46AM +0100, Manuel Bouyer wrote: On Fri, Jan 13, 2012 at 06:04:15AM +0100, Emmanuel Dreyfus wrote: Hi I just discovered the oddity below, on a netbsd-5 domU. Is there a reason for not calling that a bug? Does it happens only at mine? It is a bug; please send-pr. I can reproduce it with a HEAD kernel too. This seems to be i386-specific; a amd64 domU doens't crash. Spoke too soon. The amd64 domU crashes too, it just takes much more time. -- Manuel Bouyer bou...@antioche.eu.org NetBSD: 26 ans d'experience feront toujours la difference --
Re: reading /dev/mem panics a domU
Hi, I just discovered the oddity below, on a netbsd-5 domU. Is there a reason for not calling that a bug? Does it happens only at mine? # strings /dev/mem /dev/null xpq_flush_queue: 1 entries 0xa8b5e948: 0x0221 panic: HYPERVISOR_mmu_update failed No, this is not a bug, especially not, if this is run by root. /dev/mem is by definition the possibility to access the physical address space of the machine. That is, apart from allowing access to the physical memory, it also allows access to memory mapped I/O etc. Reading sequentially through this may or may not stumble upon one of these addresses before getting some error result (depending on the machine in question and the access rights). Access to /dev/mem requires specially crafted tools that know what they are doing. Regarding the mentioning of root in my first sentence, what I meant was that in (most of) our ports, there is code in the kernel that (depending on the secmodel in place) allows non-root users access only to real memory and returns an error otherwise (which happens to be wrong anyway, as it returns KAUTH_RESULT_* values as errno values, as I just found out when looking into this). From a security POV, access to /dev/mem should be restricted to root anyway (ok, based on the secmodel in place. However, the current restriction of non-root access to memory only doesn't make too much sense; maybe a relict from some early frame buffer access?) Ciao, Wolfgang -- wolfg...@solfrank.net Wolfgang Solfrank
Re: reading /dev/mem panics a domU
On Fri, Jan 13, 2012 at 02:03:15PM +0100, Wolfgang Solfrank wrote: Hi, I just discovered the oddity below, on a netbsd-5 domU. Is there a reason for not calling that a bug? Does it happens only at mine? # strings /dev/mem /dev/null xpq_flush_queue: 1 entries 0xa8b5e948: 0x0221 panic: HYPERVISOR_mmu_update failed No, this is not a bug, especially not, if this is run by root. It is a bug in the sense that the kernel should not ask the hypervisor to map nonextistent memory. -- Manuel Bouyer bou...@antioche.eu.org NetBSD: 26 ans d'experience feront toujours la difference --
