* Dan Williams <dan.j.willi...@intel.com> wrote:
> > - why is the patch mucking with access to PCI and BIOS space? Is the
> > persistent memory even mappable in those regions? Or is the concern
> > that userspace can access control registers associated with the
> > persistent memory? What is the problem scenario?
>
> It seems to me that letting /dev/mem do arbitrary access to any region
> of memory is a dangerous capability for a production environment.
So basically the original motivation years ago was to disable /dev/mem
altogether:
it used to be a wide open roothole if anything with write access to it (such as
old Xorg) is exploited, plus it's a favorite and convenient tool for stealth
access to system areas of memory in cases where the attacker already has root.
(this is relevant as even being root might not give easy access to system mmio
areas if things like being able to load modules is restricted even for room,
and
if the system has readonly storage and a few other things configured.)
But we couldn't disable /dev/mem completely due to Xorg and dosemu legacies -
so
we came up with this restriction feature that limits its scope.
Any additional steps that limit the scope of access under the STRICT_DEVMEM
option
(which is really a misnomer: it should be RESTRICT_DEVMEM instead) are welcome
from a generic Linux distro POV.
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
