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

From: Ingo Molnar
Date: Tue Nov 26 2019 - 15:02:32 EST



* Ingo Molnar <mingo@xxxxxxxxxx> wrote:

>
> * Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> > On Mon, Nov 25, 2019 at 8:16 AM Ingo Molnar <mingo@xxxxxxxxxx> 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