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

[Maciej S. Szmigiero]

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