linux-kernel - Re: [patch 5/9] x86/ioport: Reduce ioperm impact for sane usage further

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5AAEF116-EC9D-4C58-878F-9D27189E123A@zytor.com>
Date:   Thu, 07 Nov 2019 02:50:20 -0800
From:   hpa@...or.com
To:     Willy Tarreau <w@....eu>
CC:     Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...nel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        LKML <linux-kernel@...r.kernel.org>,
        the arch/x86 maintainers <x86@...nel.org>,
        Stephen Hemminger <stephen@...workplumber.org>,
        Juergen Gross <jgross@...e.com>,
        Sean Christopherson <sean.j.christopherson@...el.com>
Subject: Re: [patch 5/9] x86/ioport: Reduce ioperm impact for sane usage further

On November 7, 2019 2:27:56 AM PST, Willy Tarreau <w@....eu> wrote:
>On Thu, Nov 07, 2019 at 02:19:19AM -0800, hpa@...or.com wrote:
>> >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.
>
>Doing these, sure, but doing these while ranges are really checked ?
>I mean, the MMU grants you access to the pages you were assigned. Here
>with the I/O bitmap you just have to ask for access to port X and you
>get it. I could understand the benefit if we had EBUSY in return but
>that's not the case, you can actually request access to a port range
>another device driver or process is currently using, and mess up with
>what it does even by accident. I remember streaming 1-bit music in
>userland from the LED of my floppy drive in the late-90s, it used to
>cause some trouble to the floppy driver when using mtools in parallel
>:-)
>
>Willy

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.)

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.