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]
Date: Fri, 21 Jun 2024 15:17:42 +0200
From: Borislav Petkov <bp@...en8.de>
To: Steve Wahl <steve.wahl@....com>
Cc: Ashish Kalra <ashish.kalra@....com>,
	Dave Hansen <dave.hansen@...ux.intel.com>,
	Andy Lutomirski <luto@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>, x86@...nel.org,
	"H. Peter Anvin" <hpa@...or.com>, linux-kernel@...r.kernel.org,
	Pavin Joseph <me@...injoseph.com>,
	Eric Hagberg <ehagberg@...il.com>,
	Simon Horman <horms@...ge.net.au>,
	Eric Biederman <ebiederm@...ssion.com>,
	Dave Young <dyoung@...hat.com>, Sarah Brofeldt <srhb@....dk>,
	Russ Anderson <rja@....com>, Dimitri Sivanich <sivanich@....com>,
	Hou Wenlong <houwenlong.hwl@...group.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Baoquan He <bhe@...hat.com>, Yuntao Wang <ytcoode@...il.com>,
	Bjorn Helgaas <bhelgaas@...gle.com>, Joerg Roedel <jroedel@...e.de>,
	Michael Roth <michael.roth@....com>
Subject: Re: [PATCH 0/3] Resolve problems with kexec identity mapping

On Mon, Jun 17, 2024 at 10:10:32AM -0500, Steve Wahl wrote:
> The first, hardest step is locate a system that is AMD based, SEV
> capable, with a BIOS that chooses to locate the CC_BLOB at addresses
> that do not share a 2M page with other chunks of memory the kernel
> currently adds to the kexec identity map. I.e. This is a stroke of
> luck,

Ya think?

It is more likely that I win the lottery than finding such a beast. ;-\

> and for all I know could depend on configuration such as memory
> size in addition to motherboard and BIOS version.  However, it does
> not seem to change from boot to boot; as system that has the problem
> seems to be consistent about it.
> 
> Second, boot linux including the "nogbpages" command line option.
> 
> Third, kexec -l <kernel image> --append=<command line options>
> --initrd=<initrd>.
> 
> Fourth, kexec -e.
> 
> Systems that have this problem successfully kexec without the
> "nogbpages" parameter, but fail and do a full reboot with the
> "nogbpages" parameter.  
> 
> I wish I could be more exact,

Yes, this doesn't really explain what the culprit is.

So, your 0th message says:

"But the community chose instead to avoid referencing this memory on
non-AMD systems where the problem was reported.

    commit bee6cf1a80b5 ("x86/sev: Do not try to parse for the CC blob
                          on non-AMD hardware")"

But that patch fixes !AMD systems.

Now you're basically saying that there are some AMD machines out there where
the EFI config table doesn't get mapped because it is somewhere else, outside
of the range of a 2M page or 1G page.

Or even if it is, "nogbpages" supplied on the cmdline would cause the
"overlapping 2M and 1G mapping to not happen, leaving the EFI config table
unmapped.

Am I on the right track here?

-- 
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