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 421151DFEF; Wed, 20 Nov 2024 12:59: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=1732107542; cv=none; b=MNcdxXVzgehn1F4XM991uxA0pZKZ95K4bVfkkSYA5y7m6dXfDJjcCxuiZLWJyAj2wf+ZZmMnxejvAgvI2wq3Cpj9Lc0Ly34/lrICrBmfCTcFOoRI6sFekdk7rL1yRIemDYwcenopsgUd3PI+74srnDuCrhh33dEvLjY/VMxD1R8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1732107542; c=relaxed/simple; bh=COKaUunbj+OnATXnBjJejagYXCJP9BXboDwfATU1vWg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=ooaNT6DtuGcV9Wgu/+nVN9mWc5q91GBfloc0QyhzTlOFqPFhR7xwQwdN0QbCqKMuky618Uzp3XfRZsQQ6U9oY17NqkeifJBsQsphzDPFTT07T0FSVsog/lj+OJLCH83Uljw10PF1/c2Nog12UHygIh6CvFUJfQXWpkAu3DboTY8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=ZdymbXuC; 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="ZdymbXuC" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0E305C4CECD; Wed, 20 Nov 2024 12:59:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1732107542; bh=COKaUunbj+OnATXnBjJejagYXCJP9BXboDwfATU1vWg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ZdymbXuCwOnFq4vBVpA7netuPOLun+oYANk3B9U8UABYwYhOPoe5XgUlVo91Dkxg7 nil25JZk1De6Zd0Gj1dc/dutO6piZx4gfSxv9zx4wOIT2uh6TfDGjIggUZ5VccKMeo ZkCn+kdjJYdEvDa/47/Es8KMK3iJniSlJ+PzHHAk= 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 6.11 040/107] x86/mm: Fix a kdump kernel failure on SME system when CONFIG_IMA_KEXEC=y Date: Wed, 20 Nov 2024 13:56:15 +0100 Message-ID: <20241120125630.580946116@linuxfoundation.org> X-Mailer: git-send-email 2.47.0 In-Reply-To: <20241120125629.681745345@linuxfoundation.org> References: <20241120125629.681745345@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 6.11-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 @@ -655,7 +655,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; } @@ -717,7 +718,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; }