Messages in this thread | | | From | (Eric W. Biederman) | Date | Thu, 07 Nov 2019 10:45:09 -0600 | Subject | Re: [patch 5/9] x86/ioport: Reduce ioperm impact for sane usage further |
| |
Willy Tarreau <w@1wt.eu> writes:
> On Thu, Nov 07, 2019 at 02:50:20AM -0800, hpa@zytor.com wrote: >> You get access to the ports you are assigned, just like pages you are >> assigned... the rest is kernel policy, or, for that matter, privileged >> userspace (get permissions to the necessary ports, then drop privilege... the >> usual stuff.) > > I agree, my point is that there's already no policy checking at the > moment ports are assigned, hence a process having the permissions to > request just port 0x70-0x71 to read the hwclock will also have permission > to request access to the sensor chip a 0x2E and trigger a watchdog > reset or stop the CPU fan. Thus any policy enforcement is solely done > by the requesting process itself, assuming it doesn't simply use iopl() > already, which grants everything. > > This is why I'm really wondering if the real use cases that need all > this stuff still exist at all in practice.
My memory is that the applications that didn't need fine grain access to ports would just use iopl.
Further a quick look shows that dosemu uses ioperm in a fine grained manner. From memory it would allow a handful of ports to allow directly accessing a device and depended on the rest of the port accesses to be disallowed so it could trap and emulate them.
So yes I do believe making ioperm ioperm(all) will break userspace.
Eric
| |