Re: [PATCH] x86/cpufeatures: Cleanup AMD speculation feature bits

[David Woodhouse]

On Fri, 2018-01-26 at 17:14 -0600, Tom Lendacky wrote:
> On 1/26/2018 4:10 PM, Borislav Petkov wrote:
> > 
> > On Fri, Jan 26, 2018 at 09:59:44PM +0000, David Woodhouse wrote:
> > > 
> > > If we wanted to do this kind of thing, we'd do it the other way round.
> > > Turn the *Intel* feature into both 'IBRS' and 'IBPB' CPU-visible
> > > features, and have those defined in the AMD word.
> > You lost me here: have those defined in the AMD word?
> > 
> > > 
> > > Then use virtual bits with "" for the software features, since we
> > > don't want *those* to appear in /proc/cpuinfo.
> > Whatever we do, I think it would be most consistent to have three
> > strings, *both* on Intel and AMD visible in cpuinfo: "ibrs", "ibpb" and
> > "stibp" so that there's no confusion what is enabled on each box.
> > 
> > Now, those three can be the *virtual* features which get set by the
> > actual CPUID features on init. And the latter, the *actual* CPUID
> > features don't need to be visible in cpuinfo: people shouldn't care
> > whether "spec_ctrl" on Intel and "pred_cmd" on AMD both mean "ibpb". It
> > should be simply "ibpb" on both vendors in cpuinfo.
> > 
> > Ditto for the others.
> > 
> > This way you have one unified message of what is enabled on *any* box.
> That sounds good to me.

Yes, that's what I meant. Expose "ibpb", "ibrs" and "stibp" in
/proc/cpuinfo, which happen to line up with what's in the AMD CPUID
word so let's use the AMD ones as the visible ones.

The Intel bits just will set those. I'll do that now...

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