Re: [PATCH for-4.11] x86/spec_ctrl: Updates to retpoline-safety decision making

["Jan Beulich" <JBeulich@suse.com>]

>>> On 19.04.18 at 12:26, <andrew.cooper3@citrix.com> wrote:
> On 19/04/18 10:00, Jan Beulich wrote:
>>>>> On 18.04.18 at 20:13, <andrew.cooper3@citrix.com> wrote:
>>> @@ -177,18 +192,37 @@ static bool __init retpoline_safe(void)
>>>           * versions.
>>>           */
>>>      case 0x3d: /* Broadwell */
>>> -        return ucode_rev >= 0x28;
>>> +        return ucode_rev >= 0x2a;
>>>      case 0x47: /* Broadwell H */
>>> -        return ucode_rev >= 0x1b;
>>> +        return ucode_rev >= 0x1d;
>>>      case 0x4f: /* Broadwell EP/EX */
>>> -        return ucode_rev >= 0xb000025;
>>> +        return ucode_rev >= 0xb000021;
>>>      case 0x56: /* Broadwell D */
>>> -        return false; /* TBD. */
>>> +        switch ( boot_cpu_data.x86_mask )
>>> +        {
>>> +        case 2:  return ucode_rev >= 0x15;
>>> +        case 3:  return ucode_rev >= 0x7000012;
>>> +        case 4:  return ucode_rev >= 0xf000011;
>>> +        case 5:  return ucode_rev >= 0xe000009;
>>> +        default: return false;
>>> +        }
>>> +        break;
>> Hmm, the white paper says
>> "The predictable speculative behavior of the RET instruction is the key to
>>  retpoline being a robust mitigation. RET has this behavior on all processors
>>  which are based on the Intel® microarchitecture codename Broadwell and
>>  earlier when updated with the latest microcode."
>>
>> Am I to assume the text is imprecise, or else why is it that only Broadwells
>> are being checked for ucode version?
> 
> Hmm yes - that does look like poor wording in the whitepaper.  It is the
> case that Broadwell is the only uarch which needs the microcode check.

Would you mind clarifying this in the patch description (I don't think Intel
would, even if we told them, be overly quick with changing that wording
to match reality)?

Jan


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