Re: [Xen-devel] [PATCH v10 08/11] x86/boot: Calculate the most appropriate BTI mitigation to use

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 24.01.18 at 14:12, <andrew.cooper3@xxxxxxxxxx> wrote:
> See the logic and comments in init_speculation_mitigations() for further
> details.
> 
> There are two controls for RSB overwriting, because in principle there are
> cases where it might be safe to forego rsb_native (Off the top of my head,
> SMEP active, no 32bit PV guests at all, no use of vmevent/paging subsystems
> for HVM guests, but I make no guarantees that this list of restrictions is
> exhaustive).
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

With the exception of the Intel model specific things
Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
Nevetherless ...

> ---
> CC: Jan Beulich <JBeulich@xxxxxxxx>
> CC: Asit K Mallick <asit.k.mallick@xxxxxxxxx>
> CC: Jun Nakajima <jun.nakajima@xxxxxxxxx>
> 
> TODO: Confirm Broadwell microcode details, and Atom safety WRT retpoline.
> These details should not block this series.

... I agree here, and hence the ack implied by the R-b extends to this.

> @@ -147,6 +237,50 @@ void __init init_speculation_mitigations(void)
>      else if ( thunk == THUNK_JMP )
>          setup_force_cpu_cap(X86_FEATURE_IND_THUNK_JMP);
>  
> +    if ( boot_cpu_has(X86_FEATURE_IBRSB) )
> +    {
> +        /*
> +         * Even if we've chosen to not have IBRS set in Xen context, we still
> +         * need the IBRS entry/exit logic to virtualise IBRS support for
> +         * guests.
> +         */
> +        if ( ibrs )
> +            setup_force_cpu_cap(X86_FEATURE_XEN_IBRS_SET);
> +        else
> +            setup_force_cpu_cap(X86_FEATURE_XEN_IBRS_CLEAR);
> +
> +        default_bti_ist_info |= BTI_IST_WRMSR | ibrs;
> +    }
> +
> +    /*
> +     * PV guests can poison the RSB to any virtual address from which
> +     * they can execute a call instruction.  This is necessarily outside
> +     * of the Xen supervisor mappings.
> +     *
> +     * With SMEP enabled, the processor won't speculate into user mappings.
> +     * Therefore, in this case, we don't need to worry about poisoned entries
> +     * from 64bit PV guests.
> +     *
> +     * 32bit PV guest kernels run in ring 1, so use supervisor mappings.
> +     * If a processors speculates to 32bit PV guest kernel mappings, it is
> +     * speculating in 64bit supervisor mode, and can leak data.
> +     */
> +    if ( opt_rsb_native )
> +    {
> +        setup_force_cpu_cap(X86_FEATURE_RSB_NATIVE);
> +        default_bti_ist_info |= BTI_IST_RSB;
> +    }
> +
> +    /*
> +     * HVM guests can always poison the RSB to point at Xen supervisor
> +     * mappings.
> +     */
> +    if ( opt_rsb_vmexit )
> +        setup_force_cpu_cap(X86_FEATURE_RSB_VMEXIT);
> +
> +    /* (Re)init BSP state how that default_bti_ist_info has been calculated. 
> */

... now that ...

Jan


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