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: <ZoxOt1_w7nblRQCv@swahl-home.5wahls.com>
Date: Mon, 8 Jul 2024 15:40:23 -0500
From: Steve Wahl <steve.wahl@....com>
To: Borislav Petkov <bp@...en8.de>
Cc: Steve Wahl <steve.wahl@....com>, Ard Biesheuvel <ardb@...nel.org>,
        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, Jul 08, 2024 at 09:58:10PM +0200, Borislav Petkov wrote:
> On Mon, Jul 08, 2024 at 02:29:05PM -0500, Steve Wahl wrote:
> > Yes, this is about AMD machines which support SEV, running bare metal.
> > ("Server" is in question, one of my testers is known to be using a
> > laptop, so the facilities must be present in non-servers as well.)
> 
> No, they can't be. SEV is supported only on server, not on client. This laptop
> has a different problem it seems.

Ahhh.  On the laptop, it's not looking *at* the CC blob that's the
problem.

Its looking *for* the CC blob in the EFI config table; the CC blob
probably does not exist in that table on the laptop.  But the EFI
config table needs to be identity mapped, to look through it and see
that the CC blob is not there, and the EFI config table is not mapped.

I think the existence of the CC blob in the EFI config table is being
used, more or less, as a flag as to whether we need to do SEV related
code.  Without mapping the EFI config table, we can't look for that
blob.

> > As far as I can see it, the effort you're putting into finding a
> > different solution must mean you find something less than desirable
> > about the solution I have offered.  But at this point, I don't
> > understand why;
> 
> Why would we parse the CC blob which is destined *solely* for a SEV- *guest*,
> when booting the baremetal kernel which is *not* a guest?
> 
> This is the solution I'm chasing - don't do something you're not supposed to
> or needed to do.

What you're saying suggests that, maybe, my patch #2 will not be
necessary.  The CC blob will never be present except for in a guest.
But can you do a kexec to a new kernel within that guest?  If so,
patch #2 might still be necessary.

Anyway, I think the references you're trying to eliminate when they're
not needed are the references used to determine if the SEV feature is
to be used in this specific boot iteration or not.

--> Steve
-- 
Steve Wahl, Hewlett Packard Enterprise