* [GIT PULL] x86/iopl changes for v5.5
@ 2019-11-25 16:16 Ingo Molnar
2019-11-25 19:24 ` Ingo Molnar
` (2 more replies)
0 siblings, 3 replies; 9+ messages in thread
From: Ingo Molnar @ 2019-11-25 16:16 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-kernel, Thomas Gleixner, Borislav Petkov, Peter Zijlstra,
Andrew Morton, Andy Lutomirski
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [GIT PULL] x86/iopl changes for v5.5
2019-11-25 16:16 [GIT PULL] x86/iopl changes for v5.5 Ingo Molnar
@ 2019-11-25 19:24 ` Ingo Molnar
2019-11-26 9:45 ` Ingo Molnar
2019-11-26 19:30 ` [GIT PULL] x86/iopl changes " pr-tracker-bot
2019-11-26 19:33 ` Linus Torvalds
2 siblings, 1 reply; 9+ messages in thread
From: Ingo Molnar @ 2019-11-25 19:24 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-kernel, Thomas Gleixner, Borislav Petkov, Peter Zijlstra,
Andrew Morton, Andy Lutomirski
* 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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [GIT PULL] x86/iopl changes for v5.5
2019-11-25 19:24 ` Ingo Molnar
@ 2019-11-26 9:45 ` Ingo Molnar
2019-11-26 21:04 ` [GIT PULL] x86/urgent fix " Ingo Molnar
0 siblings, 1 reply; 9+ messages in thread
From: Ingo Molnar @ 2019-11-26 9:45 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-kernel, Thomas Gleixner, Borislav Petkov, Peter Zijlstra,
Andrew Morton, Andy Lutomirski
* 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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [GIT PULL] x86/iopl changes for v5.5
2019-11-25 16:16 [GIT PULL] x86/iopl changes for v5.5 Ingo Molnar
2019-11-25 19:24 ` Ingo Molnar
@ 2019-11-26 19:30 ` pr-tracker-bot
2019-11-26 19:33 ` Linus Torvalds
2 siblings, 0 replies; 9+ messages in thread
From: pr-tracker-bot @ 2019-11-26 19:30 UTC (permalink / raw)
To: Ingo Molnar
Cc: Linus Torvalds, linux-kernel, Thomas Gleixner, Borislav Petkov,
Peter Zijlstra, Andrew Morton, Andy Lutomirski
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [GIT PULL] x86/iopl changes for v5.5
2019-11-25 16:16 [GIT PULL] x86/iopl changes for v5.5 Ingo Molnar
2019-11-25 19:24 ` Ingo Molnar
2019-11-26 19:30 ` [GIT PULL] x86/iopl changes " pr-tracker-bot
@ 2019-11-26 19:33 ` Linus Torvalds
2019-11-26 19:50 ` Ingo Molnar
2 siblings, 1 reply; 9+ messages in thread
From: Linus Torvalds @ 2019-11-26 19:33 UTC (permalink / raw)
To: Ingo Molnar
Cc: Linux Kernel Mailing List, Thomas Gleixner, Borislav Petkov,
Peter Zijlstra, Andrew Morton, Andy Lutomirski
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [GIT PULL] x86/iopl changes for v5.5
2019-11-26 19:33 ` Linus Torvalds
@ 2019-11-26 19:50 ` Ingo Molnar
2019-11-26 20:02 ` Ingo Molnar
0 siblings, 1 reply; 9+ messages in thread
From: Ingo Molnar @ 2019-11-26 19:50 UTC (permalink / raw)
To: Linus Torvalds
Cc: Linux Kernel Mailing List, Thomas Gleixner, Borislav Petkov,
Peter Zijlstra, Andrew Morton, Andy Lutomirski
* 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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [GIT PULL] x86/iopl changes for v5.5
2019-11-26 19:50 ` Ingo Molnar
@ 2019-11-26 20:02 ` Ingo Molnar
0 siblings, 0 replies; 9+ messages in thread
From: Ingo Molnar @ 2019-11-26 20:02 UTC (permalink / raw)
To: Linus Torvalds
Cc: Linux Kernel Mailing List, Thomas Gleixner, Borislav Petkov,
Peter Zijlstra, Andrew Morton, Andy Lutomirski
* 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
^ permalink raw reply [flat|nested] 9+ messages in thread
* [GIT PULL] x86/urgent fix for v5.5
2019-11-26 9:45 ` Ingo Molnar
@ 2019-11-26 21:04 ` Ingo Molnar
2019-11-27 1:30 ` pr-tracker-bot
0 siblings, 1 reply; 9+ messages in thread
From: Ingo Molnar @ 2019-11-26 21:04 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-kernel, Thomas Gleixner, Borislav Petkov, Peter Zijlstra,
Andrew Morton, Andy Lutomirski
* 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);
^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [GIT PULL] x86/urgent fix for v5.5
2019-11-26 21:04 ` [GIT PULL] x86/urgent fix " Ingo Molnar
@ 2019-11-27 1:30 ` pr-tracker-bot
0 siblings, 0 replies; 9+ messages in thread
From: pr-tracker-bot @ 2019-11-27 1:30 UTC (permalink / raw)
To: Ingo Molnar
Cc: Linus Torvalds, linux-kernel, Thomas Gleixner, Borislav Petkov,
Peter Zijlstra, Andrew Morton, Andy Lutomirski
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
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2019-11-27 1:30 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-11-25 16:16 [GIT PULL] x86/iopl changes for v5.5 Ingo Molnar
2019-11-25 19:24 ` Ingo Molnar
2019-11-26 9:45 ` Ingo Molnar
2019-11-26 21:04 ` [GIT PULL] x86/urgent fix " Ingo Molnar
2019-11-27 1:30 ` pr-tracker-bot
2019-11-26 19:30 ` [GIT PULL] x86/iopl changes " pr-tracker-bot
2019-11-26 19:33 ` Linus Torvalds
2019-11-26 19:50 ` Ingo Molnar
2019-11-26 20:02 ` Ingo Molnar
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).