[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALCETrX4wrVhXToC9oqo3Ma+smKf_8bhHD-D2FGxj3iGZ=ag6g@mail.gmail.com>
Date: Thu, 30 Jul 2015 22:11:40 -0700
From: Andy Lutomirski <luto@...capital.net>
To: Borislav Petkov <bp@...en8.de>
Cc: Paolo Bonzini <pbonzini@...hat.com>,
Peter Zijlstra <peterz@...radead.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Willy Tarreau <w@....eu>, Steven Rostedt <rostedt@...dmis.org>,
X86 ML <x86@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Brian Gerst <brgerst@...il.com>
Subject: Re: Dealing with the NMI mess
On Thu, Jul 30, 2015 at 9:22 PM, Borislav Petkov <bp@...en8.de> wrote:
> On Thu, Jul 30, 2015 at 02:22:06PM -0700, Andy Lutomirski wrote:
>> Great. There's an opcode that invokes an interrupt gate that's not
>> marked as allowing unprivileged access, and that opcode doesn't appear
>> in the SDM. It appears in the APM opcode map with no explanation at
>> all.
>>
>> Thanks, CPU vendors.
>
> Here's something better:
>
> http://www.rcollins.org/secrets/opcodes/ICEBP.html
This instruction is awesome. Binutils can disassemble it (it's called
"icebp") but it can't assemble it. KVM has special handling for it on
VMX and actually reports it to QEMU on SVM (complete with a defined
ABI). We have an asm macro so we can assemble it for 32-bit but not
64-bit, despite the fact that it works on 64-bit.
The kernel instruction decoder can't decode it.
Fortunately, it looks like the vm86 case is correct (or as correct as
any of the vm86 junk can be), although I haven't tested it. I bet
that icebp is like int3 in that it punches through vm86 mode instead
of sending #GP.
--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists