linux-kernel - Re: [PATCH 1/2] x86/boot: Fix memremap of setup

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] [day] [month] [year] [list]

Date:   Thu, 24 Feb 2022 10:13:32 -0500
From:   Ross Philipson <ross.philipson@...cle.com>
To:     Borislav Petkov <bp@...en8.de>
Cc:     linux-kernel@...r.kernel.org, x86@...nel.org,
        daniel.kiper@...cle.com, dpsmith@...rtussolutions.com,
        tglx@...utronix.de, mingo@...hat.com, hpa@...or.com,
        luto@...capital.net, kanth.ghatraju@...cle.com,
        trenchboot-devel@...glegroups.com
Subject: Re: [PATCH 1/2] x86/boot: Fix memremap of setup_indirect structures

On 2/24/22 08:42, Borislav Petkov wrote:
> On Tue, Feb 22, 2022 at 04:01:32PM -0500, Ross Philipson wrote:
>> In the ioremap.c module, the check for NULL is only missing in the
>> functions we updated but the lack of a check was already there before
>> these changes went in.
>>
>> In the setup.c and e820.c modules, the check for NULL is missing in the
>> functions we updated but the lack of a check was already there before
>> these changes went in in those functions. The lack of early_memremap()
>> NULL checks can also be found in other functions in those modules.
> 
> I don't know how to understand this statement: are you saying that,
> because there are other cases where - for whatever reason - the retval
> check is not taking place - you should not do it either?
> 
> Because I can see other places where the return value is checked. I
> mean, if the return value check doesn't matter, why not make this
> function simply void and not bother at all?

Sorry if I am being vague. I will try to clarify.

In the functions I made changes to, some already checked return values
from early_memremap and some didn't prior to my changes. In addition,
there are other places/functions in those files that did not check
return values from early_memremap.

I did a search yesterday and found there are other places where the
return value from early_memremap is not checked in files I did not
touch. In general the handling of return values from early_memremap is
very inconsistent throughout arch/x86.

> 
>> Fixing it in other functions and possibly elsewhere in the arch/x86 code
>> seems to be out of scope for this patch set. We could send separate
>> patches and hunt down other places this check is missing.
> 
> That would be appreciated.

I will submit a follow on patch set that chases down all the places
where early_memremap return values are not checked and fix them. In
addition I will do the same for early_ioremap since it seems to have the
same issues throughout arch/x86.

Thanks
Ross

> 
> Thx.
>