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

[Andrea Arcangeli <aarcange@redhat.com>]

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.