On 25.02.2025 23:01, Andrew Cooper wrote: > 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.
Hmm, okay: Reviewed-by: Jan Beulich <[email protected]> Jan
