On 28/10/2024 1:18 pm, Jan Beulich wrote:
> On 24.10.2024 15:22, Andrew Cooper wrote:
>> This was true in the K10 days, but even back then the match registers were
>> really payload data rather than header data.
>>
>> But, it's really model specific data, and these days typically part of the
>> signature, so is random data for all intents and purposes.
>>
>> No functional change.
>>
>> Signed-off-by: Andrew Cooper <[email protected]>
>> ---
>> CC: Jan Beulich <[email protected]>
>> CC: Roger Pau Monné <[email protected]>
>>
>> The single difference from this is:
>>
>>   @@ -207587,7 +207587,7 @@
>>    ffff82d0402ad261: 4c 89 ce                mov    %r9,%rsi
>>    ffff82d0402ad264: 4c 39 c8                cmp    %r9,%rax
>>    ffff82d0402ad267: 0f 82 c2 11 f6 ff       jb     ffff82d04020e42f 
>> <amd_ucode_parse.cold+0x55>
>>   -ffff82d0402ad26d: 41 83 f9 3f             cmp    $0x3f,%r9d
>>   +ffff82d0402ad26d: 41 83 f9 1f             cmp    $0x1f,%r9d
>>    ffff82d0402ad271: 0f 86 b8 11 f6 ff       jbe    ffff82d04020e42f 
>> <amd_ucode_parse.cold+0x55>
>>    ffff82d0402ad277: 85 ed                   test   %ebp,%ebp
>>    ffff82d0402ad279: 75 55                   jne    ffff82d0402ad2d0 
>> <amd_ucode_parse+0x170>
>>
>> which is "mc->len < sizeof(struct microcode_patch)" expression in
>> amd_ucode_parse().
> Yet is it correct to effectively relax that check, i.e. to accept something
> we previously would have rejected?

Yes.  This is the bounds check about whether it's safe to look at fields
in the header.  It's not part of the other validity checks.

~Andrew

Reply via email to