Messages in this thread | | | Date | Thu, 7 Nov 2019 10:17:04 +0100 | From | Willy Tarreau <> | Subject | Re: [patch 5/9] x86/ioport: Reduce ioperm impact for sane usage further |
| |
On Thu, Nov 07, 2019 at 09:25:41AM +0100, Ingo Molnar wrote: > I.e. the model I'm suggesting is that if a task uses ioperm() or iopl() > then it should have a bitmap from that point on until exit(), even if > it's all zeroes or all ones. Most applications that are using those > primitives really need it all the time and are using just a few ioports, > so all the tracking doesn't help much anyway.
I'd go even further, considering that any task having called ioperm() or iopl() once is granted access to all 64k ports for life: if the task was granted access to any port, it will be able to request access for any other port anyway. And we cannot claim that finely filtering accesses brings any particular reliability in my opinion, considering that it's generally possible to make the system really sick by starting to play with most I/O ports. So for me that becomes a matter of trusted vs not trusted task. Then we can simply have two pages of 0xFF to describe their I/O access bitmap.
> On a related note, another simplification would be that in principle we > could also use just a single bitmap and emulate iopl() as an ioperm(all) > or ioperm(none) calls. Yeah, it's not fully ABI compatible for mixed > ioperm()/iopl() uses, but is that ABI actually being relied on in > practice?
You mean you'd have a unified map for all tasks ? In this case I think it's simpler and equivalent to simply ignore the values in the calls and grant full perms to the 64k ports range after the calls were validated. I could be totally wrong and missing something obvious though.
Regards, Willy
| |