x86/iopl: Fake iopl(3) CLI/STI usage
authorPeter Zijlstra <peterz@infradead.org>
Fri, 17 Sep 2021 09:20:04 +0000 (11:20 +0200)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Thu, 18 Nov 2021 18:15:56 +0000 (19:15 +0100)
commit5742269ad0cd4b5ce4972e8222e2832120baea55
treee76b6eccd5292c3c73ce012c7a76c747c89b68ac
parentdead44f5c5a0f815c9ad755ec1e8cbb232776474
x86/iopl: Fake iopl(3) CLI/STI usage

commit b968e84b509da593c50dc3db679e1d33de701f78 upstream.

Since commit c8137ace5638 ("x86/iopl: Restrict iopl() permission
scope") it's possible to emulate iopl(3) using ioperm(), except for
the CLI/STI usage.

Userspace CLI/STI usage is very dubious (read broken), since any
exception taken during that window can lead to rescheduling anyway (or
worse). The IOPL(2) manpage even states that usage of CLI/STI is highly
discouraged and might even crash the system.

Of course, that won't stop people and HP has the dubious honour of
being the first vendor to be found using this in their hp-health
package.

In order to enable this 'software' to still 'work', have the #GP treat
the CLI/STI instructions as NOPs when iopl(3). Warn the user that
their program is doing dubious things.

Fixes: a24ca9976843 ("x86/iopl: Remove legacy IOPL option")
Reported-by: Ondrej Zary <linux@zary.sk>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@kernel.org # v5.5+
Link: https://lkml.kernel.org/r/20210918090641.GD5106@worktop.programming.kicks-ass.net
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
arch/x86/include/asm/insn-eval.h
arch/x86/include/asm/processor.h
arch/x86/kernel/process.c
arch/x86/kernel/traps.c
arch/x86/lib/insn-eval.c