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

Re: [PATCH for-4.15] x86/ucode: Fix microcode payload size for Fam19 processors

  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • Date: Wed, 10 Feb 2021 13:06:45 +0000
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4I24MA5PNI/EgwkSnWseXrKXGL1J6wOkrf8NckIIML0=; b=WlcG+2ycbGCb0mwuhHyO4GPedLkt8WxzavTluBPvKKjHNz31QoByydACK9QQ8ml/l1PEEassH2cC1OJLQhW38te6VI3WboAXusU3WhsQAASSV1+xztq/3+HJgUmwLxZly62W+op7KyFm0qWr4+bROnN1OclG7OuoG2mqZIhjV/x3T7dwgDDg0ylhqiSnc5TuNCwF6bR7MSEoHusPb4P/JUUMsfsJy4rbeAEUG9nmSYgrWXRkbqiW6xVoySjKYlBTnRCCth9rNl+zSwonVVSq5D7M/uTWpXTJxxoceLsTL8ZD7vZREeruehaFJqJvG8XXH98AzA29yynEj6F5gYImSA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hF9tMdzRed9mAUZ4dSYPVTPJdqLTmmcfBr4KuHYA/1IbSNx8TVWBqq4r48/rY2bk+jRDHSu7F2arGOqD1VfaTkyinpWGYVI38giP6Aq11z5phbQ/rMqXjF8bYrAsvQLOuaOX7S5tvBtDDhsbl1rreNhu3HSAYJvu/1URGM6mP+OvUjWh733Edlweidwn8Q5Fgl35CzKsG+BDnVQXe6lnCjAgWgB/rOokTrmilAeaqt7ROjh39ZW6GCUT0cDZj9XsOlOuqmy8j5MoCyJtaLWasAXz5O+Z2deOJahV7Jvj4Cfp4/Km009QwPobHr0Ug56032uh/NIFr2K4l4FwSpG+cw==
  • Authentication-results: esa5.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • Cc: Roger Pau Monné <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Ian Jackson <iwj@xxxxxxxxxxxxxx>
  • Delivery-date: Wed, 10 Feb 2021 13:07:02 +0000
  • Ironport-sdr: WYDf+LBokPn6T9yRJqGgcFXZ0bm8FK96Hf5QRTJL7tkK7wktdhT045h5WVK6u40iP3AAmQomMC 8Ytp/rIJnunVTsaGDFE38bVJWxQO/92MQGtcN95cjHp3Jkn2DSKWXgQ2YLvgE0LMf7Eb9ST/2S Co0QM6ytjOUuD8toatDyk0VxOXjkLGRz8w1vMQxmldPVGITKi4/I9rpPZkOt+Q+ZTG7QbxxIXH qBCiE9pcrGml5geaUUr0PkHvnCs0Kildk1hXp6fEWVPeOAlP7I8C+QI19/PovqWam9f7vtW1hj vnU=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 10/02/2021 08:37, Jan Beulich wrote:
> On 09.02.2021 18:39, Andrew Cooper wrote:
>> On 09/02/2021 17:17, Ian Jackson wrote:
>>> Jan Beulich writes ("Re: [PATCH for-4.15] x86/ucode: Fix microcode payload 
>>> size for Fam19 processors"):
>>>> On 09.02.2021 16:33, Andrew Cooper wrote:
>>>>> The original limit provided wasn't accurate.  Blobs are in fact rather 
>>>>> larger.
>>>>> Fixes: fe36a173d1 ("x86/amd: Initial support for Fam19h processors")
>>>>> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
>>>> Acked-by: Jan Beulich <jbeulich@xxxxxxxx>
>>>>> --- a/xen/arch/x86/cpu/microcode/amd.c
>>>>> +++ b/xen/arch/x86/cpu/microcode/amd.c
>>>>> @@ -111,7 +111,7 @@ static bool verify_patch_size(uint32_t patch_size)
>>>>>  #define F15H_MPB_MAX_SIZE 4096
>>>>>  #define F16H_MPB_MAX_SIZE 3458
>>>>>  #define F17H_MPB_MAX_SIZE 3200
>>>>> -#define F19H_MPB_MAX_SIZE 4800
>>>>> +#define F19H_MPB_MAX_SIZE 5568
>>>> How certain is it that there's not going to be another increase?
>>>> And in comparison, how bad would it be if we pulled this upper
>>>> limit to something that's at least slightly less of an "odd"
>>>> number, e.g. 0x1800, and thus provide some headroom?
>>> 5568 does seem really an excessively magic number...
>> It reads better in hex - 0x15c0.  It is exactly the header,
>> match/patch-ram, and the digital signature of a fixed algorithm.
> And I realize it's less odd than Fam16's 3458 (0xd82).

This particular value is under investigation.  Firmware packages for
Fam16's have the blob size at 0xd60.

>> Its far simpler than Intel's format which contains multiple embedded
>> blobs, and support for minor platform variations within the same blob.
>> There are a lot of problems with how we do patch verification on AMD
>> right now, but its all a consequence of the header not containing a
>> length field.
>> This number wont change now.  Zen3 processors are out in the world.
> Given history on earlier families, where in some cases sizes
> also vary by model, how can this fact guarantee anything?

There is one example where it changed, and it got shorter.  Making it
larger would involve someone re-laying out the core so more silicon area
could be used for patch ram space, which is increasingly unlikely with
newer models in the same family.

When 4.16 comes, I do have plans to try and make us more robust to
changes in debug builds, particularly given the lack of suitable
documentation on the matter.




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