[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



Andrew Cooper writes ("Re: [PATCH for-4.15] x86/ucode: Fix microcode payload 
size for Fam19 processors"):
> 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"):
...
> >> 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.
> 
> 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.

Err.  This Is Fine.

Release-Acked-by: Ian Jackson <iwj@xxxxxxxxxxxxxx>



 


Rackspace

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