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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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?

Jan


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