Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
Date:   Wed, 29 Jun 2022 08:52:54 -0500
From:   Michael Roth <michael.roth@amd.com>
To:     NOMURA =?utf-8?B?SlVOSUNISSjph47mnZHjgIDmt7PkuIAp?= 
        <junichi.nomura@nec.com>
CC:     Borislav Petkov <bp@alien8.de>,
        LKML <linux-kernel@vger.kernel.org>,
        "x86@kernel.org" <x86@kernel.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)
Message-ID: <20220629135254.cicvyp5clm4s4n35@amd.com>
References: <TYCPR01MB694815CD815E98945F63C99183B49@TYCPR01MB6948.jpnprd01.prod.outlook.com>
 <20220629004114.zn5rurrmqdkiceun@amd.com>
 <OSZPR01MB6953EEF3F8E63330547E031183BB9@OSZPR01MB6953.jpnprd01.prod.outlook.com>
 <YrwLS8qRDhjmeD5Z@zn.tnic>
 <TYCPR01MB6948029FAACBC313063EE49283BB9@TYCPR01MB6948.jpnprd01.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <TYCPR01MB6948029FAACBC313063EE49283BB9@TYCPR01MB6948.jpnprd01.prod.outlook.com>
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jun 2022 13:55:06.0584
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 64ae7be6-6094-4606-ce86-08da59d6f8f7
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource: BN8NAM11FT052.eop-nam11.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB5517
X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,
        RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS,T_SCC_BODY_TEXT_LINE
        autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, Jun 29, 2022 at 11:06:00AM +0000, NOMURA JUNICHI(野村 淳一) wrote:
> From: Borislav Petkov <bp@alien8.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.
>