* Dan Williams <dan.j.williams@xxxxxxxxx> 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-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
