Re: [Xen-devel] Spectre Mitigations in Xen 4.6

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 20.03.18 at 13:58, <jandryuk@xxxxxxxxx> wrote:
> I've been experimenting with Linux 4.14 on Xen 4.6.  Now that Intel
> microcode is generally
> available, I'm starting to exercise the new mitigation code paths.
> 
> For Xen 4.6-4.8, microcode loading happens after
> init_speculation_mitigations, so Xen only
> detects the boot firmware features.  The early microcode loading
> f97838bbd980 ("x86: Move
> microcode loading earlier") can be cherry-picked, though small fix ups
> are needed for
> bool/true/false -> bool_t/1/0 and smpboot.c:smp_store_cpu_info() to
> retain "struct
> cpuinfo_x86 *c = cpu_data + id;".

Oh, I see - yes, I'll need to pull that in. I didn't notice it's missing
because the test box already had suitable microcode (by way of a
BIOS update done in January).

> With that in place, I'm seeing Dom0 receive a general protection fault on 
> boot
> 
> [   25.460035] general protection fault: 0000 [#1] SMP
> [   25.460292] EIP: switch_mm_irqs_off+0xbe/0x600
> 
> switch_mm_irqs_off+0xbe is the inlined
> indirect_branch_prediction_barrier(void)
> {
>         alternative_msr_write(MSR_IA32_PRED_CMD, PRED_CMD_IBPB,
>                               X86_FEATURE_USE_IBPB);
> }
> 
> The system boots when dom0 disables IBPB manipulation with
> nospectre_v2 on the kernel
> command line.
> 
> I think Xen ends up here in xen/arch/x86/traps.c:emulate_privileged_op(),
>         case MSR_PRED_CMD:
>             domain_cpuid(currd, 7, 0, &dummy, &dummy, &dummy, &edx);
>             domain_cpuid(currd, 0x80000008, 0, &dummy, &ebx, &dummy, &dummy);
>             if ( !(edx & cpufeat_mask(X86_FEATURE_IBRSB)) &&
>                  !(ebx & cpufeat_mask(X86_FEATURE_IBPB)) )
>                 goto fail; /* MSR available? */
> 
>             /*
>              * The only defined behaviour is when writing PRED_CMD_IBPB.  In
>              * practice, real hardware accepts any value without faulting.
>              */
>             if ( eax & PRED_CMD_IBPB )
>                 wrmsrl(MSR_PRED_CMD, PRED_CMD_IBPB);
>             break;
> 
> ...but Dom0 doesn't have a cpuid policy configured, so the IBRSB/IBPB
> check fails and we GP.
> Did I read that correctly?  If that is the case, how should Dom0 be handled?

Hmm, using pv_cpuid() instead isn't really a good option, as that
wants struct cpu_user_regs passed in. So I guess we'll have to
mimic what pv_cpuid() does for Dom0 in the priv-op emulation
code. I'll cook up a patch...

Jan


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