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

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: <bce73502-0d18-e50c-b78b-8159dc9f8f66@maciej.szmigiero.name>
Date:   Tue, 1 May 2018 00:27:51 +0200
From:   "Maciej S. Szmigiero" <mail@...iej.szmigiero.name>
To:     Borislav Petkov <bp@...en8.de>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        "H. Peter Anvin" <hpa@...or.com>, x86@...nel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v5 4/6] x86/microcode/AMD: Check microcode container data
 in the late loader

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