[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a85c28b8-1255-3264-bb4a-89e85e3c6009@sr71.net>
Date: Mon, 12 Feb 2018 08:13:31 -0800
From: Dave Hansen <dave@...1.net>
To: Ingo Molnar <mingo@...nel.org>, hpa@...or.com, tglx@...utronix.de,
torvalds@...ux-foundation.org, linux-kernel@...r.kernel.org,
dwmw@...zon.co.uk, peterz@...radead.org
Cc: linux-tip-commits@...r.kernel.org, Borislav Petkov <bp@...en8.de>,
Arjan van de Ven <arjan@...radead.org>
Subject: Re: [tip:x86/pti] x86/speculation: Use IBRS if available before
calling into firmware
On 02/12/2018 02:22 AM, Ingo Molnar wrote:
>> +static inline void firmware_restrict_branch_speculation_end(void)
>> +{
>> + alternative_msr_write(MSR_IA32_SPEC_CTRL, 0,
>> + X86_FEATURE_USE_IBRS_FW);
> BTW., there's a detail that only occurred to me today, this enabling/disabling
> sequence is not NMI safe, and it might be called from NMI context:
FWIW, Tim Chen and I talked about this a bunch. We ended up just
saving/restoring the MSR verbatim in the NMI handler the same way we do
CR3, stashing it in a high general-purpose-register (r%12?). That costs
a RDMSR (at least) and an WRMSR (which you can optimize out). We have a
patch for that somewhere if anybody wants it.
We also came to the same conclusion that it's a rather challenging thing
to exploit these cases, especially when you consider that we can easily
do RSB stuffing on NMI exit just before going back to the firmware.
Powered by blists - more mailing lists