linux-kernel - Re: [PATCH 0/3] Resolve problems with kexec identity mapping

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: <ZnmNKAE5qT48yhrI@swahl-home.5wahls.com>
Date: Mon, 24 Jun 2024 10:13:44 -0500
From: Steve Wahl <steve.wahl@....com>
To: Borislav Petkov <bp@...en8.de>
Cc: Steve Wahl <steve.wahl@....com>, 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 Fri, Jun 21, 2024 at 03:17:42PM +0200, Borislav Petkov wrote:
> 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. ;-\

Yes, that is the impression I was trying to impart!  :-)

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

I haven't heard of one where using 1G pages doesn't include this EFI
table.  But if you switch to 2M pages using "nogbpages", that's when
you get into trouble.

(Also trouble if you switch to using some 2M pages using patch #3,
which is the point of the series.)

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

I think so.  The EFI config table is being included by luck, not
explicitly; "nogbpages" switches to using 2M pages only, greatly
reducing the range of addresses unintentionally included in the map.
So the EFI config table doesn't end up mapped.

> Am I on the right track here?

I believe so.

Patch #3's intent is/was to reduce the amount of space unintentionally
included in the identity map, to avoid speculation into areas that
cause system halts on HPE's UV hardware.  It does so by using 1G pages
for large areas and 2M pages for smaller areas.  It should have worked
for systems in general, without being specific to UV, but when it got
into the mainline kernel, it was found to cause a regression on these
AMD systems, and was reverted.

The regression turned out to be the EFI config table not being mapped.

Patch #1 fixes this problem for the EFI config table, and patch #2
fixes it for the CC BLOB that is also likely accessed.

These accesses are a problem because they happen prior to establishing
the page fault interrupt handler that would mend the identity map.  I
know very little about the AMD SEV feature but reading the code I
think it may be required to do this before setting up that handler.

Thanks,

--> Steve

-- 
Steve Wahl, Hewlett Packard Enterprise