Re: [Xen-devel] [PATCH v2 for-4.7/4.8] x86: Fix "x86: further CPUID handling adjustments"

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 18.05.18 at 15:23, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 18/05/18 13:37, Jan Beulich wrote:
>>>>> On 18.05.18 at 14:21, <andrew.cooper3@xxxxxxxxxx> wrote:
>>> On 17/05/18 13:23, Jan Beulich wrote:
>>>>>>> On 16.05.18 at 19:27, <andrew.cooper3@xxxxxxxxxx> wrote:
>>>>> c/s 62b187969 "x86: further CPUID handling adjustments" make some 
>>>>> adjustments.
>>>>> However, it breaks levelling of guests, making it impossible for the 
>>>>> toolstack
>>>>> to hide STIBP or IBPB from guests on hardware with up-to-date microcode.
>>>>>
>>>>> The dom0 issue referenced in the commit message was fixed by the hunk
>>>>> adjusting the zeroing alone.  STIBP and IBPB don't need (and indeed, must 
>>>>> not
>>>>> be for levelling purposes) OR'd into the leaf.
>>>>>
>>>>> One final item which was missed in backport was the need to ignore the
>>>>> toolstack choice of STIBP, and set it equal to IBRSB.  This needs doing 
>>>>> after
>>>>> the mask has been applied.
>>>>>
>>>>> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
>>>> What about the patch below instead? This then allows the tool stack to 
>>>> override
>>>> STIBP independent of IBRSB.
>>>>
>>>> Jan
>>>>
>>>> x86: correct "further CPUID handling adjustments"
>>>>
>>>> Commit 62b187969 "x86: further CPUID handling adjustments" went too far,
>>>> breaking feature levelling of DomU-s. Restrict the PV overrides to just
>>>> Dom0 and undo the HVM overrides.
>>> Why?  PV overrides (for dom0 or domU) are equally wrong.
>> Why do you talk about DomU? Those overrides are being removed by the
>> proposed patch. For Dom0, otoh, there's no other way to do the "IBRSB
>> implies both STIBP and IBPB" override we otherwise advertise to the tool
>> stack via the PV and HVM feature sets. And I can't see why we wouldn't
>> want to treat Dom0 equally in this regard. Even on master I think we only
>> do the STIBP part of the above, while the IBPB part is only done for the
>> feature sets.
>>
>> Furthermore, as indicated before, I'm not convinced overriding STIBP
>> when the tool stack may have intentionally masked it (as your patch
>> does, and as I understand is the effect of
>>
>>     /*
>>      * Override STIBP to match IBRS.  Guests can safely use STIBP
>>      * functionality on non-HT hardware, but can't necesserily protect
>>      * themselves from SP2/Spectre/Branch Target Injection if STIBP is hidden
>>      * on HT-capable hardware.
>>      */
>>     p->feat.stibp = p->feat.ibrsb;
>>
>> in master) is the right thing to do.
> 
> I'm not sure how to answer this than simply with "yes it is".  We do not
> tolerate the toolstack creating invalid configurations, and seeing STIBP
> without IBRSB is invalid.

But I'm talking about the opposite: The tool stack clearing STIBP but
keeping IBRSB set. The invalid configuration you mention can only
happen if someone enabled STIBP in the guest config, and if there
really was no checking anywhere (after all the feature set reported
to the tool stack is sane, as you explain further down). But how would
that be different from someone enabling e.g. AVX in the guest config
when the underlying hardware doesn't have AVX?

> Until the Xen/toolstack CPUID handling improvements get posted, Xen's
> only recourse to bad toolstack configuration is to correct it, and we do
> this to any CPUID information we don't like.  In the future, we will
> fail a toolstack hypercall which passes bad configuration.
> 
> The featureset side of consistency is handled by
> guest_common_feature_adjustments()
> 
> /*
>  * If IBRS is offered to the guest, unconditionally offer STIBP.  It is a
>  * nop on non-HT hardware, and has this behaviour to make heterogeneous
>  * setups easier to manage.
>  */
> 
> if ( test_bit(X86_FEATURE_IBRSB, fs) )
>     __set_bit(X86_FEATURE_STIBP, fs);
> 
> which, in combination with the featureset dependency logic, ensures that
> the max featuresets see a consistent view for these features.

Exactly.

> The IBRSB implies IBRS corner case is more problematic.  Before the

I assume you mean IBPB instead of IBRS here? Iirc we don't have code
for the separate AMD side IBRS (and their form of STIBP) just yet.

> cpuid_policy changes, dom0 saw a wildly different set of CPUID values,
> and even now, still sees an increased set.  I'm not sure its worth
> trying to fix on the older branches, because there are much larger holes
> with CPUID handling.

We shouldn't make older versions behave artificially inconsistent with
master. We do surface IBPB to Dom0 on Intel hardware with IBRSB there.
Hence unless it's technically impossible we should do so in backports as
well.

I would actually go a step further and say that "cpuid=no-ibrsb" should
still surface IBPB to guests (Xen itself perhaps ought to honor the request
and refrain from issuing barriers, albeit that effect could also be achieved
by "spec-ctrl=no-ibpb").

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel