Adam Jackson, le mer. 07 nov. 2018 15:09:58 -0500, a ecrit: > Because the kernel is the one thing in a position to enforce access > exclusion.
root-owned processes can still use ioperm to get access to io ports and break that. > If you try to implement this with a userspace arbiter then > all you need to do to break it is run an old version of libpciaccess. Sure. Except if ioperm is allowed only for the pci arbiter. > > > The 'x86' backend is fundamentally broken (as you've noticed) > > > > How do you see it broken? (considering that the concurrent access issue > > is solved by moving it to a central place) > > 1) PCI configuration space access isn't atomic. Sure, that's what I was talking about. Having only one pci arbiter solves this. > I'll assume that the design you're contemplating has a pci arbiter > server handling the actual port I/O, and that for normal processes > inl/outl would trap and relay the command to the arbiter. Normal process would use the hurd libpciaccess method, i.e. through the pci arbiter. > 2) No support for multiple PCI domains, because the CF8/CFC access > method doesn't have any way to encode a domain. Sure, we'd need to extend this to get support for that. > 3) No support for things that aren't x86. Not a concern for Hurd, > perhaps, but if that's a thing you ever want maybe solve it portably up > front. Sure, again, that'd be extendable later. Really, think the pci arbiter as the kernel driver you are mentioning, simply running in userland, and for now using the libpciaccess x86 method, which is a way to share the implementation. Remember that I did implement that method actually, precisely to have it usable both by GNU/Hurd, but also other projects which would happen to be happy to have it (cygwin seem to have been happy with it). There are various server-based OSes out there which are happy to be able to re-use it, even if they don't take the time to port the configure bits into upstream libpciaccess. Samuel _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
