lkml.org 
[lkml]   [2019]   [Nov]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [patch 5/9] x86/ioport: Reduce ioperm impact for sane usage further
    From
    On November 7, 2019 2:00:27 AM PST, Thomas Gleixner <tglx@linutronix.de> wrote:
    >On Thu, 7 Nov 2019, Willy Tarreau wrote:
    >> 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.
    >
    >Changing ioperm(single port, port range) to be ioperm(all) is going to
    >break a bunch of test cases which actually check whether the permission
    >is
    >restricted to a single I/O port or the requested port range.
    >
    >Thanks,
    >
    > tglx

    This seems very undesirable... as much as we might wish otherwise, the port bitmap is the equivalent to the MMU, and there are definitely users doing direct device I/O out there.
    --
    Sent from my Android device with K-9 Mail. Please excuse my brevity.

    \
     
     \ /
      Last update: 2019-11-07 11:22    [W:3.853 / U:0.112 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site