linux-kernel - Re: [GIT PULL] x86/iopl changes for v5.5

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: <20191126200226.GA5785@gmail.com>
Date:   Tue, 26 Nov 2019 21:02:26 +0100
From:   Ingo Molnar <mingo@...nel.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Borislav Petkov <bp@...en8.de>,
        Peter Zijlstra <a.p.zijlstra@...llo.nl>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Andy Lutomirski <luto@...nel.org>
Subject: Re: [GIT PULL] x86/iopl changes for v5.5


* Ingo Molnar <mingo@...nel.org> wrote:

> 
> * Linus Torvalds <torvalds@...ux-foundation.org> wrote:
> 
> > On Mon, Nov 25, 2019 at 8:16 AM Ingo Molnar <mingo@...nel.org> wrote:
> > >
> > > This tree implements a nice simplification of the iopl and ioperm code
> > > that Thomas Gleixner discovered: we can implement the IO privilege
> > > features of the iopl system call by using the IO permission bitmap in
> > > permissive mode, while trapping CLI/STI/POPF/PUSHF uses in user-space if
> > > they change the interrupt flag.
> > 
> > I've pulled it.
> > 
> > But do we have a test for something like this:
> > 
> >    ioperm(.. limited set of ports..)
> >    access that limited set.
> > 
> >    special_sequence() {
> >        iopl(3);
> >        access some extended set
> >        iopl(0)
> >    }
> > 
> >    go back to access the limited set again
> > 
> > because there's subtle interactions with people using *both* iopl()
> > and ioperm() and switching between the two. Historically you could
> > trivially do the above, because they are entirely independent
> > operations. Does it still work?
> > 
> > Too busy/lazy to check myself.
> 
> Yes, I went through the code with such scenarios in mind and I believe it 
> all works correctly: the two bitmaps are independent and the granular one 
> is preserved across iopl() interactions. But to make sure I'll write a 
> testcase as well.
> 
> In any case I agree that this kind of behavior is very much part of the 
> ABI, so if it doesn't work like that we'll fix it. :-)

Thomas already coded a similar testcase up in tools/testing/selftests/x86/ioperm.c:

 galatea:/home/mingo/linux/linux/tools/testing/selftests/x86> ./iopl_64 
 [OK]	CLI faulted
 [OK]	STI faulted
 [OK]	outb to 0x80 worked
 [OK]	outb to 0x80 worked
 [OK]	outb to 0xed failed
	child: set IOPL to 3
 [RUN]	child: write to 0x80
 [OK]	Child succeeded
 [RUN]	parent: write to 0x80 (should fail)
 [OK]	outb to 0x80 failed
 [OK]	CLI faulted
 [OK]	STI faulted
	iopl(3)
	Drop privileges
 [RUN]	iopl(3) unprivileged but with IOPL==3
 [RUN]	iopl(0) unprivileged
 [RUN]	iopl(3) unprivileged
 [OK]	Failed as expected

This is the testcase:

        /* Establish an I/O bitmap to test the restore */
        if (ioperm(0x80, 1, 1) != 0)
                err(1, "ioperm(0x80, 1, 1) failed\n");

        /* Restore our original state prior to starting the fork test. */
        if (iopl(0) != 0)
                err(1, "iopl(0)");

        /*
         * Verify that IOPL emulation is disabled and the I/O bitmap still
         * works.
         */
        expect_ok_outb(0x80);
        expect_gp_outb(0xed);

Those expect-OK for 0x80 and expect-#GP for 0xed are the tests for the 
previously established permission bitmap surviving to after the 
iopl(3)+iopl(0) sequence, and they work as expected:

 [OK]	outb to 0x80 worked
 [OK]	outb to 0xed failed

Thanks,

	Ingo