linux-kernel - Re: [Regression v5.19-rc1] crash kexec fails to boot the 2nd kernel (Re: [PATCH v12 38/46] x86/sev: Add SEV-SNP feature detection/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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20220629135254.cicvyp5clm4s4n35@amd.com>
Date:   Wed, 29 Jun 2022 08:52:54 -0500
From:   Michael Roth <michael.roth@....com>
To:     NOMURA JUNICHI(野村　淳一) 
        <junichi.nomura@....com>
CC:     Borislav Petkov <bp@...en8.de>,
        LKML <linux-kernel@...r.kernel.org>,
        "x86@...nel.org" <x86@...nel.org>
Subject: Re: [Regression v5.19-rc1] crash kexec fails to boot the 2nd kernel
 (Re: [PATCH v12 38/46] x86/sev: Add SEV-SNP feature detection/setup)

On Wed, Jun 29, 2022 at 11:06:00AM +0000, NOMURA JUNICHI(野村 淳一) wrote:
> From: Borislav Petkov <bp@...en8.de>
> > I still think the proper fix is to not execute that cc blob code on
> > anything but AMD...
> 
> That will solve my case but I'm afraid there may be people with AMD who
> hits the same problem.

Yah, I'd mentioned to Boris that I was only able to reproduce it on
baremetal Intel system, but that ended up being an unrelated issue due
to having KASAN enabled in my config (which seems to break kexec for me).

But the issue you're seeing I haven't been able to reproduce, and I'm
not sure what is needed to get it to reproduce, but it might not be
Intel-only.

> 
> Isn't it possible for boot loaders to pass cc_blob_address via boot_params?
> Information included in struct cc_setup_data is just 'u32 cc_blob_address'
> and it seems struct boot_params already has a place reserved for it.

We were trying to avoid exposing cc_blob_address to boot loaders
directly, since linux boot protocol seems to prefer the setup_data entry
for new parameters.

The reason the kernel uses boot_params->cc_blob_address internally is
because boot/compressed has all the helpers for early EFI parsing, and will
have already checked for the cc blob and cached it there, so the runtime
kernel just uses that instead of trying to introduce all the early EFI
parsing code into early boot and redo'ing all the parsing that
boot/compressed has already done.

So the runtime kernel relies on boot/compressed for handling EFI, and
simply uses boot_params to pass that on to runtime kernel.

But it has its own handling for cc_blob passed via setup_data entry,
because that entry point is meant for boot loaders / VMMs that use stuff
like CONFIG_PVH to jump directly into decompressed kernel: those are the
cases where we'd expect cc blob via setup_data entry. But this is a
critical thing to support right now, and if we can't find a proper fix
we can simply disable this patch and not check for setup_data entry in
runtime kernel.

But I think we might still be able to fix this properly, I had a typo
in my early patch which would be worth try, and might avoid future
issues with other early setup_data access in the future code. I
responded there with an updated patch.

-Mike

> 
> -- 
> Jun'ichi Nomura, NEC Corporation / NEC Solution Innovators, Ltd.
>