Re: reading /dev/mem panics a domU

[Wolfgang Solfrank <Wolfgang%Solfrank.net@localhost>]

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
> 0x00000000a8b5e948: 0x0000000000000221
> 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
--
Wolfgang%Solfrank.net@localhost                         Wolfgang Solfrank