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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Ygvy8j9E7WPo6dx0@zn.tnic>
Date:   Tue, 15 Feb 2022 19:37:38 +0100
From:   Borislav Petkov <bp@...en8.de>
To:     Ross Philipson <ross.philipson@...cle.com>
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 Tue, Feb 15, 2022 at 06:34:43AM -0500, Ross Philipson wrote:
> It can if you run out of slots in the fixed map.

Right. Or if any of the checks in __early_ioremap() fail. But those
would at least warn.

> The only reason I did not check it for NULL was because it was not
> checked elsewhere for NULL.

Elsewhere in the tree or elsewhere in this file or in the setup_indirect
adding code?

> I guess there are two questions:
> 
> 1. Should I also fix it elsewhere in the code I am touching?

Yes pls.

> 2. What should I do on an allocation failure? In a routine like this it
> seems to be a critical early boot failure.

How so?

I'd expect in the case of e820__reserve_setup_data(), for example, to
not call e820__range_update* and not have those indirect ranges present
in the e820 map. What the user intended might not work but it'll at
least boot instead of floating dead in the water.

And similar approach in the other places you're touching.

You could even issue a warning or so so that users at least know what's
going on. I'd say...

> I guess the original intention might have been to let it just blow up
> since there is no recovery but that is just conjecture...

The original intention?

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ