[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <3908561D78D1C84285E8C5FCA982C28F329407F2@ORSMSX114.amr.corp.intel.com>
Date: Tue, 18 Nov 2014 23:26:30 +0000
From: "Luck, Tony" <tony.luck@...el.com>
To: Andy Lutomirski <luto@...capital.net>
CC: Borislav Petkov <bp@...en8.de>, Andi Kleen <andi@...stfloor.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
X86 ML <x86@...nel.org>, Peter Zijlstra <peterz@...radead.org>,
Oleg Nesterov <oleg@...hat.com>
Subject: RE: [RFC PATCH] x86, entry: Switch stacks on a paranoid entry from
userspace
> Your test case is presumably doing something that involves setting
> undocumented registers* to program the CPU or memory controller to
> generate a machine check on access to some address. Presumably this
> is done by broadcasting an SMI and programming the registers in SMM.
Good theory - but not quite how it works. The ACPI/EINJ table does trigger
an SMI so the BIOS can do the injection. What BIOS actually does is to play
with the memory controller so that the next write to the target address will
flip some ECC bits in an unnatural way (to either plant a correctable error
with just one bit flipped, or a UC error with two bits flipped). Then the SMI
returns.
Then my application reads the target address, and we see CMCI or MCE
when the ECC check fails.
Hopefully this keeps the SMI path decoupled from the MCE ... I even sleep
a little after injection and before consumption just in case there are any
stragglers late returning from the (broadcast) SMI that planted the error.
-Tony
Powered by blists - more mailing lists