linux-kernel - Re: [PATCH 2/3] x86/microcode/AMD: Make __verify_patch

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3cc87528-e7a9-4dc0-800b-bb8f0cf279cd@suse.com>
Date: Thu, 14 Nov 2024 16:40:50 +0200
From: Nikolay Borisov <nik.borisov@...e.com>
To: Borislav Petkov <bp@...en8.de>
Cc: x86@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/3] x86/microcode/AMD: Make __verify_patch_size() return
 bool



On 14.11.24 г. 16:26 ч., Borislav Petkov wrote:
> On Thu, Nov 14, 2024 at 04:13:33PM +0200, Nikolay Borisov wrote:
>>>           if (sh_psize != max_size)
>>>                   return false;
>>
>> Isn't sh_psize < max_size valid here?
> 
> * sh_psize < min_t(u32, buf_size, max_size) == max_size -- ditto.
> 
> This is still some sort of a mismatch which we'd rather fail.
> 
> That max_size should probably be called patch_size or so.
> 
> IOW, if the patch size in the header doesn't match the per-family patch size
> => fail.

Right, the important bit here is that max_size is not really max_size 
but, as you say, patch_size so for those families it's expected to have 
an exact size.

With max_size I perceive it would imply that the current patch can be 
_at most_ max_size, but might as well be smaller.



>