[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALCETrXDORrTifXjkf06QyhEDUumR8NBiAq5Tw_JLTt=iCB=Xw@mail.gmail.com>
Date: Thu, 30 Jul 2015 14:22:06 -0700
From: Andy Lutomirski <luto@...capital.net>
To: Paolo Bonzini <pbonzini@...hat.com>
Cc: 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>,
Borislav Petkov <bp@...en8.de>,
Thomas Gleixner <tglx@...utronix.de>,
Brian Gerst <brgerst@...il.com>
Subject: Re: Dealing with the NMI mess
On Thu, Jul 30, 2015 at 8:41 AM, Paolo Bonzini <pbonzini@...hat.com> wrote:
>
>
> On 24/07/2015 23:08, Andy Lutomirski wrote:
>> user_icebp is set if int $0x01 happens, except it isn't because user
>> code can't actually do that -- it'll cause #GP instead.
>>
>> user_icebp is also set if the user has a bloody in-circuit emulator,
>> given the name. But who on Earth has one of those on a system new
>> enough to run Linux and, even if they have one, why on Earth are they
>> using it to send SIGTRAP.
>
> You do not need either "int $0x01" or an ICE to set user_icebp = 1. You
> can use the 0xf1 opcode, which is kinda like 0xcc but generates #DB
> instead of #BP.
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.
--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