Re: [Xen-devel] [PATCH v10 01/11] x86/cpuid: Handling of IBRS/IBPB, STIBP and IBRS for guests

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 01/02/18 09:06, Jan Beulich wrote:
>>>> On 24.01.18 at 14:12, <andrew.cooper3@xxxxxxxxxx> wrote:
>> --- a/xen/arch/x86/cpuid.c
>> +++ b/xen/arch/x86/cpuid.c
>> @@ -383,6 +383,16 @@ static void __init calculate_pv_max_policy(void)
>>      /* Unconditionally claim to be able to set the hypervisor bit. */
>>      __set_bit(X86_FEATURE_HYPERVISOR, pv_featureset);
>>  
>> +    /* On hardware with IBRS/IBPB support, there are further adjustments. */
>> +    if ( test_bit(X86_FEATURE_IBRSB, pv_featureset) )
>> +    {
>> +        /* Offer STIBP unconditionally.  It is a nop on non-HT hardware. */
>> +        __set_bit(X86_FEATURE_STIBP, pv_featureset);
>> +
>> +        /* AMD's IBPB is a subset of IBRS/IBPB. */
>> +        __set_bit(X86_FEATURE_IBPB, pv_featureset);
>> +    }
>> +
>>      sanitise_featureset(pv_featureset);
>>      cpuid_featureset_to_policy(pv_featureset, p);
>>      recalculate_xstate(p);
>> @@ -440,6 +450,16 @@ static void __init calculate_hvm_max_policy(void)
>>              __clear_bit(X86_FEATURE_XSAVES, hvm_featureset);
>>      }
>>  
>> +    /* On hardware with IBRS/IBPB support, there are further adjustments. */
>> +    if ( test_bit(X86_FEATURE_IBRSB, hvm_featureset) )
>> +    {
>> +        /* Offer STIBP unconditionally.  It is a nop on non-HT hardware. */
>> +        __set_bit(X86_FEATURE_STIBP, hvm_featureset);
>> +
>> +        /* AMD's IBPB is a subset of IBRS/IBPB. */
>> +        __set_bit(X86_FEATURE_IBPB, hvm_featureset);
>> +    }
> One more thing regarding these changes, and their implications
> on migration: If a capable guest is started on a system without
> hardware support and then migrated to a system with hardware
> support, it will continue to run unprotected. I do realize that
> reporting the features to guests (and ignoring the MSR accesses)
> on incapable hardware is not nice either (as it will give the guest a
> false sense of security), but was that option at least considered
> (perhaps as non-default behavior), so that after migration such a
> guest would then be secure?

Trapping and ignoring the MSRs (especially for HVM guests) is going to
be a far higher overhead than even using the MSRs, and using the MSRs
comes with a steep perf hit.

The far more subtle problem occurs when migrating between a Broadwell
and Skylake CPU, where your choice of which mitigations to use changes.

It would be good for VMs in general to have a way of knowing they have
been migrated, and re-evaluating their idea of the world.  That,
combined with an explicit administrator decision to increase the visible
featureset of the VM would be a reasonable solution to this (and other)
problems.

~Andrew

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