[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On 19/01/18 14:01, Jan Beulich wrote:
>>>> On 18.01.18 at 16:46, <andrew.cooper3@xxxxxxxxxx> wrote:
>> +/* Calculate whether Retpoline is known-safe on this CPU. */
>> +static bool __init retpoline_safe(void)
>> +{
>> +    unsigned int ucode_rev = this_cpu(ucode_cpu_info).cpu_sig.rev;
>> +
>> +    if ( boot_cpu_data.x86_vendor == X86_VENDOR_AMD )
>> +        return true;
>> +
>> +    if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL ||
>> +         boot_cpu_data.x86 != 6 )
>> +        return false;
>> +
>> +    switch ( boot_cpu_data.x86_model )
>> +    {
>> +    case 0x17: /* Penryn */
>> +    case 0x1d: /* Dunnington */
>> +    case 0x1e: /* Nehalem */
>> +    case 0x1f: /* Auburndale / Havendale */
>> +    case 0x1a: /* Nehalem EP */
>> +    case 0x2e: /* Nehalem EX */
>> +    case 0x25: /* Westmere */
>> +    case 0x2c: /* Westmere EP */
>> +    case 0x2f: /* Westmere EX */
>> +    case 0x2a: /* SandyBridge */
>> +    case 0x2d: /* SandyBridge EP/EX */
>> +    case 0x3a: /* IvyBridge */
>> +    case 0x3e: /* IvyBridge EP/EX */
>> +    case 0x3c: /* Haswell */
>> +    case 0x3f: /* Haswell EX/EP */
>> +    case 0x45: /* Haswell D */
>> +    case 0x46: /* Haswell H */
>> +        return true;
> Especially regarding this part of the function (leave the other half
> in context for reference) - can we perhaps shorten this? E.g.
> fold together everything below the lowest Broadwell model value?

No.  The numbers aren't linear and we don't have confirmation that
retpoline is safe on those CPUs.  What will happen in practice on the
older CPUs is that we see a lack of IBRS (no microcode) and a lack of
any other option, and fall back to repotline (i.e. no change from the
compiled binary) as it is better than nothing, if not completely safe.

> There in particular don't appear to be an Atoms in the list above,
> yet either they're affected by the underlying issue as well (and
> hence would benefit from whatever applicable mitigation), or we
> should suppress as much mitigation overhead as possible for them
> (which I don't think is the case).

Some Atoms are definitely affected, but I've not had any confirmation on
affected models.

>
> In any event, as said before - this function will need an ack from
> an Intel person, and it would be nice for ...
>
>> +        /*
>> +         * Broadwell processors are retpoline-safe after specific microcode
>> +         * versions.
>> +         */
>> +    case 0x3d: /* Broadwell */
>> +        return ucode_rev >= 0x28;
>> +    case 0x47: /* Broadwell H */
>> +        return ucode_rev >= 0x1b;
>> +    case 0x4f: /* Broadwell EP/EX */
>> +        return ucode_rev >= 0xb000025;
>> +    case 0x56: /* Broadwell D */
>> +        return false; /* TBD. */
> ... this to be filled in.

Still waiting.  I don't think this should block the patch going in.

~Andrew

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.