On Wed, Sep 26, 2018 at 11:15:14PM +0000, Haralanov, Mitko wrote: > On Wed, 2018-09-26 at 16:11 -0600, Jason Gunthorpe wrote: > > Probably the same thing, you can't let user space control a DMA > > engine, so arbitary userspace writes to a PCI bar are totally > > forbidden. > > > > But, if there is a totally secure region in the BAR that is safe, > > then > > potentially read/write could be OK. But there would need to be a big > > comment explaining the logic around picking the reduced region in the > > BAR, and what the security model is. > > Jason, > > Your assertion does not make sense to me WRT the scenario below. Would > you mind elaborating or pointing us the discussion related to this? > > A 'root' user can certainly unload a device driver and then fully > access the device's BAR through the 'resourceX' sysfs. This allows > userspace to trigger DMA's at will. Not on secure boot systems, resourceX is apparently blocked. (although I'm not totally sure how..) > Not to mention that a 'root' user can load a module which exports the > entire BAR to userspace, completely circumventing any protections > available to /dev/mem or 'resourceX'. Also not on secure boot systems, they require signed modules. The entire point of secure boot is to prevent tampering with the OS kernel itself, so all means of directly manipulating kernel memory are blocked. This must obviously include blocking user space access to any DMA engine. It looks to me like the HFI1 driver can opt out of CONFIG_STRICT_DEVMEM by not marking its regsion as exclusive if that is what it wants, still won't work with secure boot, but maybe that is OK for it? Jason
