From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3DF40222D4E; Thu, 12 Dec 2024 17:13:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734023582; cv=none; b=DKVHAijSMWcMghfp556i8orI1jI1x2HxApul/ltVWlxkQ6YjH46TwEWOVsM3y/66e00CczqHXj0m0+fMyVAjfSJM9HeptM4bEX+J4oA0ihUj+M/4rn213PgEmbhA38HHhi7Z56k70jy/kLTTiqVatQpcXe0DkyKQXzfifezroGk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734023582; c=relaxed/simple; bh=Vwp3OH8nFNJw1xn5nCs5OlT6JvzgNSN67SIcRhePkTk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=PFbBmeowlGzz8cnUtWUrRphy5QCie6wF51vjRw+89rjlJoW76HrjAelVxpFqI7zpBKYPisiJDL700TreXrt+nu6pAjrJ76Rwyywo9cfxAIP36aL41TFYapRypCf02V/uRS42RyZjeMwNPW0oevwylRUcIrCaEP9rWOFyom72CmA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=PoEIbBuh; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="PoEIbBuh" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B4A12C4CED0; Thu, 12 Dec 2024 17:13:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1734023582; bh=Vwp3OH8nFNJw1xn5nCs5OlT6JvzgNSN67SIcRhePkTk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=PoEIbBuhpcSGjR3dyY0FLO9q2arjUsqnKGs3MeruJcsAEw3ghZplBDetCyfwIHiKg uJx246B7YJTDKaDDBY3vUUe9qrMeq8ZuwE2gqeadDdZGyomvARpSWxJfNcts40P1pa 5xzIH3w1LwKXzhb4RBufM3fOExzzkkh1j4BsmXAI= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Baoquan He , "Borislav Petkov (AMD)" , Tom Lendacky , stable@kernel.org Subject: [PATCH 5.10 015/459] x86/mm: Fix a kdump kernel failure on SME system when CONFIG_IMA_KEXEC=y Date: Thu, 12 Dec 2024 15:55:53 +0100 Message-ID: <20241212144254.130774620@linuxfoundation.org> X-Mailer: git-send-email 2.47.1 In-Reply-To: <20241212144253.511169641@linuxfoundation.org> References: <20241212144253.511169641@linuxfoundation.org> User-Agent: quilt/0.67 X-stable: review X-Patchwork-Hint: ignore Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 5.10-stable review patch. If anyone has any objections, please let me know. ------------------ From: Baoquan He commit 8d9ffb2fe65a6c4ef114e8d4f947958a12751bbe upstream. The kdump kernel is broken on SME systems with CONFIG_IMA_KEXEC=y enabled. Debugging traced the issue back to b69a2afd5afc ("x86/kexec: Carry forward IMA measurement log on kexec"). Testing was previously not conducted on SME systems with CONFIG_IMA_KEXEC enabled, which led to the oversight, with the following incarnation: ... ima: No TPM chip found, activating TPM-bypass! Loading compiled-in module X.509 certificates Loaded X.509 cert 'Build time autogenerated kernel key: 18ae0bc7e79b64700122bb1d6a904b070fef2656' ima: Allocated hash algorithm: sha256 Oops: general protection fault, probably for non-canonical address 0xcfacfdfe6660003e: 0000 [#1] PREEMPT SMP NOPTI CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.11.0-rc2+ #14 Hardware name: Dell Inc. PowerEdge R7425/02MJ3T, BIOS 1.20.0 05/03/2023 RIP: 0010:ima_restore_measurement_list Call Trace: ? show_trace_log_lvl ? show_trace_log_lvl ? ima_load_kexec_buffer ? __die_body.cold ? die_addr ? exc_general_protection ? asm_exc_general_protection ? ima_restore_measurement_list ? vprintk_emit ? ima_load_kexec_buffer ima_load_kexec_buffer ima_init ? __pfx_init_ima init_ima ? __pfx_init_ima do_one_initcall do_initcalls ? __pfx_kernel_init kernel_init_freeable kernel_init ret_from_fork ? __pfx_kernel_init ret_from_fork_asm Modules linked in: ---[ end trace 0000000000000000 ]--- ... Kernel panic - not syncing: Fatal exception Kernel Offset: disabled Rebooting in 10 seconds.. Adding debug printks showed that the stored addr and size of ima_kexec buffer are not decrypted correctly like: ima: ima_load_kexec_buffer, buffer:0xcfacfdfe6660003e, size:0xe48066052d5df359 Three types of setup_data info — SETUP_EFI, - SETUP_IMA, and - SETUP_RNG_SEED are passed to the kexec/kdump kernel. Only the ima_kexec buffer experienced incorrect decryption. Debugging identified a bug in early_memremap_is_setup_data(), where an incorrect range calculation occurred due to the len variable in struct setup_data ended up only representing the length of the data field, excluding the struct's size, and thus leading to miscalculation. Address a similar issue in memremap_is_setup_data() while at it. [ bp: Heavily massage. ] Fixes: b3c72fc9a78e ("x86/boot: Introduce setup_indirect") Signed-off-by: Baoquan He Signed-off-by: Borislav Petkov (AMD) Acked-by: Tom Lendacky Cc: Link: https://lore.kernel.org/r/20240911081615.262202-3-bhe@redhat.com Signed-off-by: Greg Kroah-Hartman --- arch/x86/mm/ioremap.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) --- a/arch/x86/mm/ioremap.c +++ b/arch/x86/mm/ioremap.c @@ -660,7 +660,8 @@ static bool memremap_is_setup_data(resou paddr_next = data->next; len = data->len; - if ((phys_addr > paddr) && (phys_addr < (paddr + len))) { + if ((phys_addr > paddr) && + (phys_addr < (paddr + sizeof(struct setup_data) + len))) { memunmap(data); return true; } @@ -722,7 +723,8 @@ static bool __init early_memremap_is_set paddr_next = data->next; len = data->len; - if ((phys_addr > paddr) && (phys_addr < (paddr + len))) { + if ((phys_addr > paddr) && + (phys_addr < (paddr + sizeof(struct setup_data) + len))) { early_memunmap(data, sizeof(*data)); return true; }