Re: [patch RFC 5/5] x86/speculation: Add basic speculation control code

[David Woodhouse]

On Wed, 2018-01-10 at 13:57 +0100, Andrea Arcangeli wrote:
> On Wed, Jan 10, 2018 at 01:47:22PM +0100, Jiri Kosina wrote:
> > 
> > On Wed, 10 Jan 2018, Andrea Arcangeli wrote:
> > 
> > > 
> > > Perhaps the confusing come from "less privileged prediction mode" and
> > > you thought that meant "less privileged ring mode". It says "predction
> > > mode" not ring 3.
> > Well, prediction mode is defined by "CPL3 vs CPL0-2" and "VMX root vs VMXÂ
> > non-root", with obvious ordering of privileges.
> > 
> > So if IBRS is set, branch predictor will not allow the predicted target toÂ
> > be influenced by code that executed in less privileged prediction modeÂ
> > before value of '1' IBRS mode was last written to, and that's pretty muchÂ
> > it.
> Which in current silicon IBP speculation is turned off always, and the
> above specification really is to provide more finegrined semantics
> for future silicon where it'll perform best to leave it always on and
> it'll be still as secure as it is now despite the IBP speculation may
> not always be turned off like it happens right now.
> 
> With all the prediction modes ordered right for the respective
> guest/ring and CPUID will tell us when it's higher perf to enable
> ibrs_enabled 2 ibpb_enabled 1 by default.
> 
> Again I see zero issues with leaving IBRS always on in current and
> future silicon and I see absolutely zero problems in setting IBRS in
> vmexit to prevent the whole guest mode to attack the kernel memory,
> and in fact ibrs_enabled 2 will even more secure and it'll prevent the
> gust mode userland even to attack the host qemu userland through
> spectre variant#2.
> 
> As long as the "with obvious ordering of privileges" is maintained
> when IBRS is not a total turn off of IBP speculation, everything works
> as intended.

Andrea, what you're saying is directly contradicting what I've heard
from Intel.

The documentation already distinguishes between IBRS on current
hardware, and IBRS_ATT on future hardware. If it was the case that IBRS
on current hardware is a set-and-forget option and completely disables
branch prediction, then they would say that. Rather than explicitly
saying the *opposite*, specifically for the case of current hardware,
as they do.

Rather than continuing to debate it, perhaps it's best just to wake for
the US to wake up, and Intel to give a definitive answer.

Attachment: smime.p7s
Description: S/MIME cryptographic signature