Re: [PATCH v5 4/6] x86/microcode/AMD: Check microcode container data in the late loader

Maciej S. Szmigiero
2018-04-30T22:27:55Z

On 30.04.2018 11:05, Borislav Petkov wrote:
> On Mon, Apr 23, 2018 at 11:34:09PM +0200, Maciej S. Szmigiero wrote:
>> --- a/arch/x86/kernel/cpu/microcode/amd.c
>> +++ b/arch/x86/kernel/cpu/microcode/amd.c
>> @@ -750,28 +752,20 @@ static int verify_and_add_patch(u8 family, u8 *fw, unsigned int leftover)
>> return crnt_size;
>> }
>>
>> - /*
>> - * The section header length is not included in this indicated size
>> - * but is present in the leftover file length so we need to subtract
>> - * it before passing this value to the function below.
>> - */
>> - ret = verify_patch_size(family, patch_size, leftover - SECTION_HDR_SIZE);
>> - if (!ret) {
>> - pr_err("Patch-ID 0x%08x: size mismatch.\n", mc_hdr->patch_id);
>> + if (!verify_patch(family, fw, leftover, false))
>> return crnt_size;
>> - }
>>
>> patch = kzalloc(sizeof(*patch), GFP_KERNEL);
>> if (!patch) {
>> pr_err("Patch allocation failure.\n");
>> - return -EINVAL;
>> + return 0;
>
> So by convention returning 0 is success and negative value means error.
> I don't see the reason for changing that in the whole code.

1) -EINVAL maps to a valid return value of 4294967274 bytes.
We have a different behavior for invalid data in the container file
(including too large lengths) than for grave errors like a failed memory
allocation.

2) This function single caller (__load_microcode_amd()) normalized any
error that verify_and_add_patch() returned to UCODE_ERROR anyway,

3) The existing code uses a convention that zero return value means
'terminate processing' for the parse_container() function in the early
loader which normally returns a 'bytes consumed' value, as this function
does.

Thanks,
Maciej