On Wed, Sep 26, 2018 at 09:05:20PM +0000, Weiny, Ira wrote: > > > > On Wed, Sep 26, 2018 at 07:58:11PM +0000, Haralanov, Mitko wrote: > > > > > We would be happy to implement whatever interface is deemed correct > > > but the requirement is that the 'root' user has full access to the > > > device BAR and the driver can remain loaded at the same time. > > > > The kernel community has decided not to permit that, sorry. > > > > The prohibition goes hand in hand with secure boot and a driver cannot > > defeat those restrictions. > > > > You need to figure out how to do what you want without a mmap'd BAR, or > > state your BAR is fully secured in HW. > > Can we mmap parts of the BAR? Maybe. It probably means your driver is only going to work on 4k page size though. Ie 64k page size will break it. Generally in the kernel we are not supposed to allow such non-portable things in the PCI drivers. But, that aside, you'd still have to find a 4k page that is both useful and completely secure. > Are we mainly discussing the mmap functionality of the patch or do > you see issues with the read/write functionality as well? 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. Also, some of this stuff may belong in devlink, not debugfs, but not totally sure on that. You should check. Jason
