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
