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

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

[Ingo Molnar]

Linus,

Please pull the latest x86-iopl-for-linus git tree from:

   git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-iopl-for-linus

   # HEAD: e3cb0c7102f04c83bf1a7cb1d052e92749310b46 x86/ioperm: Fix use of deprecated config option

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.

This tree implements that feature, with testing facilities and related 
cleanups.

 Thanks,

	Ingo

------------------>
Alexander Duyck (1):
      x86/ioperm: Fix use of deprecated config option

Thomas Gleixner (21):
      x86/ptrace: Prevent truncation of bitmap size
      x86/process: Unify copy_thread_tls()
      x86/cpu: Unify cpu_init()
      x86/tss: Fix and move VMX BUILD_BUG_ON()
      x86/iopl: Cleanup include maze
      x86/ioperm: Simplify first ioperm() invocation logic
      x86/ioperm: Avoid bitmap allocation if no permissions are set
      x86/io: Speedup schedule out of I/O bitmap user
      x86/tss: Move I/O bitmap data into a seperate struct
      x86/ioperm: Move iobitmap data into a struct
      x86/ioperm: Add bitmap sequence number
      x86/ioperm: Move TSS bitmap update to exit to user work
      x86/ioperm: Remove bitmap if all permissions dropped
      x86/ioperm: Share I/O bitmap if identical
      selftests/x86/ioperm: Extend testing so the shared bitmap is exercised
      x86/iopl: Fixup misleading comment
      x86/iopl: Restrict iopl() permission scope
      x86/iopl: Remove legacy IOPL option
      x86/ioperm: Extend IOPL config to control ioperm() as well
      selftests/x86/iopl: Extend test to cover IOPL emulation
      x86/entry/32: Clarify register saving in __switch_to_asm()


 arch/x86/Kconfig                        |  18 +++
 arch/x86/entry/common.c                 |   4 +
 arch/x86/entry/entry_32.S               |   8 +-
 arch/x86/include/asm/io_bitmap.h        |  29 +++++
 arch/x86/include/asm/paravirt.h         |   4 -
 arch/x86/include/asm/paravirt_types.h   |   2 -
 arch/x86/include/asm/pgtable_32_types.h |   2 +-
 arch/x86/include/asm/processor.h        | 113 ++++++++++-------
 arch/x86/include/asm/ptrace.h           |   6 +
 arch/x86/include/asm/switch_to.h        |  10 ++
 arch/x86/include/asm/thread_info.h      |  14 ++-
 arch/x86/include/asm/xen/hypervisor.h   |   2 -
 arch/x86/kernel/cpu/common.c            | 188 ++++++++++++----------------
 arch/x86/kernel/doublefault.c           |   2 +-
 arch/x86/kernel/ioport.c                | 209 +++++++++++++++++++++-----------
 arch/x86/kernel/paravirt.c              |   2 -
 arch/x86/kernel/process.c               | 205 ++++++++++++++++++++++++-------
 arch/x86/kernel/process_32.c            |  77 ------------
 arch/x86/kernel/process_64.c            |  86 -------------
 arch/x86/kernel/ptrace.c                |  12 +-
 arch/x86/kvm/vmx/vmx.c                  |   8 --
 arch/x86/mm/cpu_entry_area.c            |   8 ++
 arch/x86/xen/enlighten_pv.c             |  10 --
 tools/testing/selftests/x86/ioperm.c    |  16 ++-
 tools/testing/selftests/x86/iopl.c      | 129 ++++++++++++++++++--
 25 files changed, 686 insertions(+), 478 deletions(-)
 create mode 100644 arch/x86/include/asm/io_bitmap.h

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

[Ingo Molnar]

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

> Linus,
> 
> Please pull the latest x86-iopl-for-linus git tree from:
> 
>    git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-iopl-for-linus
> 
>    # HEAD: e3cb0c7102f04c83bf1a7cb1d052e92749310b46 x86/ioperm: Fix use of deprecated config option
> 
> 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.
> 
> This tree implements that feature, with testing facilities and related 
> cleanups.

Forgot to list the conflicts that may arise if you merge this after the 
other x86 bits.

Firstly the symbol bits would conflict here:

            arch/x86/entry/entry_32.S
            arch/x86/kernel/head_32.S
            arch/x86/xen/xen-asm_32.S

I've resolved them in tip:WIP.x86/asm if you want to double check:

   git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git WIP.x86/asm

but usually you do the resolutions better. :-)

There's also a conflict in arch/x86/include/asm/pgtable_32_types.h.

But there's also a semantic conflict that would trigger if you pull this 
after the x86/urgent bits, interacting with:

  05b042a19443: ("x86/pti/32: Calculate the various PTI cpu_entry_area sizes correctly, make the CPU_ENTRY_AREA_PAGES assert precise")

After that commit the CPU_ENTRY_AREA_PAGES value has to be precise, and 
edited to 41 in the merge commit if I did everything write with the pull 
requests.

This too is resolved in tip:WIP.x86/asm, in the following merge commits:

  22d7b9359a9a: ("Merge branch 'x86/iopl' into x86/asm, to resolve conflicts")
  7543765dd362: ("Merge branch 'x86/urgent' into x86/iopl, to resolve conflicts")

Thanks,

	Ingo

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

[Ingo Molnar]

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

> Forgot to list the conflicts that may arise if you merge this after the 
> other x86 bits.
> 
> Firstly the symbol bits would conflict here:
> 
>             arch/x86/entry/entry_32.S
>             arch/x86/kernel/head_32.S
>             arch/x86/xen/xen-asm_32.S

Note that these conflicts will arise once you merge x86-asm-for-linus, 
with an additional semantic conflict in arch/x86/crypto/blake2s-core.S, 
see my merge conflict mail to that pull request.

> There's also a conflict in arch/x86/include/asm/pgtable_32_types.h.

This asm/pgtable_32_types.h conflict will be the only conflict you'll see 
when you merge x86-iopl-for-linus:

  <<<<<<< HEAD
  #define CPU_ENTRY_AREA_PAGES    (NR_CPUS * 39)
  =======
  #define CPU_ENTRY_AREA_PAGES    (NR_CPUS * 41)
  >>>>>>> e3cb0c7102f04c83bf1a7cb1d052e92749310b46

And the correct resolution is to pick the '41' side.

Thanks,

	Ingo

[GIT PULL] x86/urgent fix for v5.5

[Ingo Molnar]

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

> > Forgot to list the conflicts that may arise if you merge this after the 
> > other x86 bits.
> > 
> > Firstly the symbol bits would conflict here:
> > 
> >             arch/x86/entry/entry_32.S
> >             arch/x86/kernel/head_32.S
> >             arch/x86/xen/xen-asm_32.S
> 
> Note that these conflicts will arise once you merge x86-asm-for-linus, 
> with an additional semantic conflict in arch/x86/crypto/blake2s-core.S, 
> see my merge conflict mail to that pull request.
> 
> > There's also a conflict in arch/x86/include/asm/pgtable_32_types.h.
> 
> This asm/pgtable_32_types.h conflict will be the only conflict you'll see 
> when you merge x86-iopl-for-linus:
> 
>   <<<<<<< HEAD
>   #define CPU_ENTRY_AREA_PAGES    (NR_CPUS * 39)
>   =======
>   #define CPU_ENTRY_AREA_PAGES    (NR_CPUS * 41)
>   >>>>>>> e3cb0c7102f04c83bf1a7cb1d052e92749310b46
> 
> And the correct resolution is to pick the '41' side.

I missed one other semantic conflict that can result in build failures on 
certain stripped down x86 32-bit configs, for example 32-bit 
"allnoconfig" where CONFIG_X86_IOPL_IOPERM gets turned off.

Here's a (tested) fix for that:

Please pull the latest x86-urgent-for-linus git tree from:

   git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-urgent-for-linus

   # HEAD: 0bcd7762727dd8ba9b9b6f828e5a4cbd5da4f725 x86/iopl: Make 'struct tss_struct' constant size again

 Thanks,

	Ingo

------------------>
Ingo Molnar (1):
      x86/iopl: Make 'struct tss_struct' constant size again


 arch/x86/include/asm/processor.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index b4e29d8b9e5a..e51afbb0cbfb 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -411,9 +411,7 @@ struct tss_struct {
 	 */
 	struct x86_hw_tss	x86_tss;
 
-#ifdef CONFIG_X86_IOPL_IOPERM
 	struct x86_io_bitmap	io_bitmap;
-#endif
 } __aligned(PAGE_SIZE);
 
 DECLARE_PER_CPU_PAGE_ALIGNED(struct tss_struct, cpu_tss_rw);

Re: [GIT PULL] x86/urgent fix for v5.5

[pr-tracker-bot]

The pull request you sent on Tue, 26 Nov 2019 22:04:43 +0100:

> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-urgent-for-linus

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/c2da5bdc66a377f0b82ee959f19f5a6774706b83

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker

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

[pr-tracker-bot]

The pull request you sent on Mon, 25 Nov 2019 17:16:26 +0100:

> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-iopl-for-linus

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/ab851d49f6bfc781edd8bd44c72ec1e49211670b

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker

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

[Linus Torvalds]

On Mon, Nov 25, 2019 at 8:16 AM Ingo Molnar <mingo@kernel.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.

              Linus

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

[Ingo Molnar]

* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Mon, Nov 25, 2019 at 8:16 AM Ingo Molnar <mingo@kernel.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. :-)

Thanks,

	Ingo

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

[Ingo Molnar]

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

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