libpciaccess on GNU/Hurd

[Samuel Thibault]

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