Message ID | 20240214221847.2066632-16-ross.philipson@oracle.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-66051-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:b825:b0:106:860b:bbdd with SMTP id da37csp23862dyb; Wed, 14 Feb 2024 14:34:40 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCU9lFgKeGC621Td7pZRhH2gbHHvm6UdjOPNOx4UvPEKQGXOUpNzrpqljwHNSyV0/ZgLbW/CP+s77qMc3Bmvi13p5pu/PA== X-Google-Smtp-Source: AGHT+IHk+z71K+Sk62bd54tIsH8srMS3GH28Qryo2JvafunmtMPYdqNNE6yyDFyaFt5Ils1lvbah X-Received: by 2002:a2e:7206:0:b0:2d1:2bdd:9968 with SMTP id n6-20020a2e7206000000b002d12bdd9968mr41556ljc.17.1707950080352; Wed, 14 Feb 2024 14:34:40 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1707950080; cv=pass; d=google.com; s=arc-20160816; b=NuiJ6r4bl/VcXHXU8bmCslrw/A67zm6CLC3XBkcDYhMOtHP1CMHlX4SC7rlTeEAwrO yKM4qh49Erugi4Q4FyN+56M4eW2L8RJdYydJYK2HgjZ4IMlcTgk6pxVX5fZ3kVceTXDd mHVaVLPK8gpPejJcrl4hlGBy3hQQlYNS3m7XxUivC2ScOS/PsKHpw6f/aVkmeaU7RrXF LgEb5N9NCuLnX6/PwxwPOzY/sde5GR6ip/yNG3sL6lRFsBIRiuC57qLOXZ3DYAUS6SCf 8S6PPTYwU8QqAZ71W8l0DzFkXouofCbSv7zagxiCKEXtTS4TbYutuotWOPEoPkq4Qi/1 CwDQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:in-reply-to:message-id :date:subject:cc:to:from:dkim-signature; bh=LywYV7sKOLgcRW6dEU5AQlOwu5jlNOpmyybhEKQBFTU=; fh=BNeeOtuZO1JBZXWIewRbhvShdBkK1yp3M5CKKcolT+4=; b=wl+4A+GklK+gcOED/lfWoeaNlLV/guF3ItMlWZmN1Dkb9ecO22UiLZxTCaTfi2d53t yjIsEnEYeeYQqRfbTGpfzGoA2x6x54JTJr/NPnXgzPKjWl2EmBWhW0ne4vfrfJMl/GUG 8H1Dstb8Qj2XqY/pIA9w1stry3X0jj6ahukkTXOaDF/9d3NU2uIMgKEfzDW3KoP1oPO/ yaxJaRrKioRdUzm/TXN9EmkQ3Hq3D7ZSmgdg1OYRej0BsuNk+teXjod9qTLvXqE2jbjb D1W5e1U4kIXVO478fYofrU2W202YAz42aFXvs3P4/iLwennrD1/QUSfuBPgK0S8aeGVP ZrcA==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2023-11-20 header.b=GafnFw2e; arc=pass (i=1 spf=pass spfdomain=oracle.com dkim=pass dkdomain=oracle.com dmarc=pass fromdomain=oracle.com); spf=pass (google.com: domain of linux-kernel+bounces-66051-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-66051-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com X-Forwarded-Encrypted: i=2; AJvYcCUovxSm0gzQkU7H2hZR/bR3PZ9zL2xJMoJiGVY3p8FFkPdydguW1+oZDT8b7vajDpFNPfGJgCz5LeZgZ36bd+wIfwdfAQ== Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [147.75.80.249]) by mx.google.com with ESMTPS id c7-20020aa7c987000000b005638ea9e307si558708edt.187.2024.02.14.14.34.40 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 14 Feb 2024 14:34:40 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-66051-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249; Authentication-Results: mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2023-11-20 header.b=GafnFw2e; arc=pass (i=1 spf=pass spfdomain=oracle.com dkim=pass dkdomain=oracle.com dmarc=pass fromdomain=oracle.com); spf=pass (google.com: domain of linux-kernel+bounces-66051-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-66051-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id BDAC71F22B49 for <ouuuleilei@gmail.com>; Wed, 14 Feb 2024 22:34:39 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 438AF146014; Wed, 14 Feb 2024 22:32:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=oracle.com header.i=@oracle.com header.b="GafnFw2e" Received: from mx0a-00069f02.pphosted.com (mx0a-00069f02.pphosted.com [205.220.165.32]) (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 968C2145B2A; Wed, 14 Feb 2024 22:32:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=205.220.165.32 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707949941; cv=none; b=NNgoyfFsg/fOh3vGGqmS8HJqzGlLzKqcHGt5uVge0/SMazvdIkzFk0d3L7QFlom5AGsRMIRHtkqRz8W477BbiXClQOO6w33qUohRlj4qtgoUB7t5V5lRLd6JRsKO7JK2rjTu6+5Jo3blzWsXqz/zKDMXxLlPc6T5ktdeG8MBS/A= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707949941; c=relaxed/simple; bh=flFnoxSjJPiZN+KWO/A4dvYo7tj50mI8G+STmxqDfgs=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=J2NzAC6GGJclP6ZPh3c7VOYT8SOvBm6+6XJF1Tcj7n6PbqsaKoQurk2M1l0dH2waJqLBE5JOi5ei0Cgh94qHFPjBAgmlD1KOzxX9tUzR1tbXYklan4X4KRFidI8OuarSgsXWezEWMVYG5JyP5ZYXrBBvvqWg0tu7rmRuL6NB9Dk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=oracle.com; spf=pass smtp.mailfrom=oracle.com; dkim=pass (2048-bit key) header.d=oracle.com header.i=@oracle.com header.b=GafnFw2e; arc=none smtp.client-ip=205.220.165.32 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=oracle.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=oracle.com Received: from pps.filterd (m0246627.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 41ELiRJJ022678; Wed, 14 Feb 2024 22:31:49 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding; s=corp-2023-11-20; bh=LywYV7sKOLgcRW6dEU5AQlOwu5jlNOpmyybhEKQBFTU=; b=GafnFw2eABZO4lj7v9fXjWJdBUyJKZDU7FdbeU9CvB6420yuZxeKEZh+v2I8qeNffQAE NgZs4j7tgGgequMTvhI0U1lg9YAbg14dayb7B0s5DkqhEV253dHbc9HOYf1ORUbYmn5a lFIH0mCHjMhOK+y3VVwvm83Vk+XPjp7nJB1MXSmN3LhC6bLypuvkHqEwmqyUweJPD6rj T1k5VRMKbwFFGGrsf4Z9oT7I/KZON3AORKBOOEMX0QjT4vMFFVYlTxH4/EmDSdkge5iG Pm7PHPtHPmvAdukUxQO3ecQZG8Zu2X2t7k6AQbstXFQyn0q1zJ/YJBo7JFp3gcMdJgw+ bw== Received: from iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta02.appoci.oracle.com [147.154.18.20]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 3w92ppghkc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 14 Feb 2024 22:31:49 +0000 Received: from pps.filterd (iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1]) by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (8.17.1.19/8.17.1.19) with ESMTP id 41EM0KMa000657; Wed, 14 Feb 2024 22:31:48 GMT Received: from pps.reinject (localhost [127.0.0.1]) by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id 3w5yk9n7hq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 14 Feb 2024 22:31:48 +0000 Received: from iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 41EMVTVO004281; Wed, 14 Feb 2024 22:31:47 GMT Received: from bur-virt-x6-2-100.us.oracle.com (bur-virt-x6-2-100.us.oracle.com [10.153.92.40]) by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id 3w5yk9n72r-16 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 14 Feb 2024 22:31:47 +0000 From: Ross Philipson <ross.philipson@oracle.com> To: linux-kernel@vger.kernel.org, x86@kernel.org, linux-integrity@vger.kernel.org, linux-doc@vger.kernel.org, linux-crypto@vger.kernel.org, kexec@lists.infradead.org, linux-efi@vger.kernel.org Cc: ross.philipson@oracle.com, dpsmith@apertussolutions.com, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, hpa@zytor.com, dave.hansen@linux.intel.com, ardb@kernel.org, mjg59@srcf.ucam.org, James.Bottomley@hansenpartnership.com, peterhuewe@gmx.de, jarkko@kernel.org, jgg@ziepe.ca, luto@amacapital.net, nivedita@alum.mit.edu, herbert@gondor.apana.org.au, davem@davemloft.net, kanth.ghatraju@oracle.com, trenchboot-devel@googlegroups.com Subject: [PATCH v8 15/15] x86: EFI stub DRTM launch support for Secure Launch Date: Wed, 14 Feb 2024 14:18:47 -0800 Message-Id: <20240214221847.2066632-16-ross.philipson@oracle.com> X-Mailer: git-send-email 2.39.3 In-Reply-To: <20240214221847.2066632-1-ross.philipson@oracle.com> References: <20240214221847.2066632-1-ross.philipson@oracle.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.1011,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2024-02-14_14,2024-02-14_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 phishscore=0 mlxscore=0 bulkscore=0 spamscore=0 malwarescore=0 adultscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2311290000 definitions=main-2402140170 X-Proofpoint-ORIG-GUID: jd8QLRG0hZFTbiXK0o9sbVAzU9z96nCn X-Proofpoint-GUID: jd8QLRG0hZFTbiXK0o9sbVAzU9z96nCn X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1790915463211778038 X-GMAIL-MSGID: 1790915463211778038 |
Series |
x86: Trenchboot secure dynamic launch Linux kernel support
|
|
Commit Message
Ross Philipson
Feb. 14, 2024, 10:18 p.m. UTC
This support allows the DRTM launch to be initiated after an EFI stub
launch of the Linux kernel is done. This is accomplished by providing
a handler to jump to when a Secure Launch is in progress. This has to be
called after the EFI stub does Exit Boot Services.
Signed-off-by: Ross Philipson <ross.philipson@oracle.com>
---
drivers/firmware/efi/libstub/x86-stub.c | 55 +++++++++++++++++++++++++
1 file changed, 55 insertions(+)
Comments
On Wed, 14 Feb 2024 at 23:32, Ross Philipson <ross.philipson@oracle.com> wrote: > > This support allows the DRTM launch to be initiated after an EFI stub > launch of the Linux kernel is done. This is accomplished by providing > a handler to jump to when a Secure Launch is in progress. This has to be > called after the EFI stub does Exit Boot Services. > > Signed-off-by: Ross Philipson <ross.philipson@oracle.com> > --- > drivers/firmware/efi/libstub/x86-stub.c | 55 +++++++++++++++++++++++++ > 1 file changed, 55 insertions(+) > > diff --git a/drivers/firmware/efi/libstub/x86-stub.c b/drivers/firmware/efi/libstub/x86-stub.c > index 0d510c9a06a4..4df2cf539194 100644 > --- a/drivers/firmware/efi/libstub/x86-stub.c > +++ b/drivers/firmware/efi/libstub/x86-stub.c > @@ -9,6 +9,7 @@ > #include <linux/efi.h> > #include <linux/pci.h> > #include <linux/stddef.h> > +#include <linux/slr_table.h> > > #include <asm/efi.h> > #include <asm/e820/types.h> > @@ -810,6 +811,57 @@ static efi_status_t efi_decompress_kernel(unsigned long *kernel_entry) > return EFI_SUCCESS; > } > > +static void efi_secure_launch(struct boot_params *boot_params) > +{ > + struct slr_entry_uefi_config *uefi_config; > + struct slr_uefi_cfg_entry *uefi_entry; > + struct slr_entry_dl_info *dlinfo; > + efi_guid_t guid = SLR_TABLE_GUID; > + struct slr_table *slrt; > + u64 memmap_hi; > + void *table; > + u8 buf[64] = {0}; > + If you add a flex array to slr_entry_uefi_config as I suggested in response to the other patch, we could simplify this substantially static struct slr_entry_uefi_config cfg = { .hdr.tag = SLR_ENTRY_UEFI_CONFIG, .hdr.size = sizeof(cfg), .revision = SLR_UEFI_CONFIG_REVISION, .nr_entries = 1, .entries[0] = { .pcr = 18, .evt_info = "Measured UEFI memory map", }, }; cfg.entries[0].cfg = boot_params->efi_info.efi_memmap | (u64)boot_params->efi_info.efi_memmap_hi << 32; cfg.entries[0].size = boot_params->efi_info.efi_memmap_size; > + table = get_efi_config_table(guid); > + > + /* > + * The presence of this table indicated a Secure Launch > + * is being requested. > + */ > + if (!table) > + return; > + > + slrt = (struct slr_table *)table; > + > + if (slrt->magic != SLR_TABLE_MAGIC) > + return; > + slrt = (struct slr_table *)get_efi_config_table(guid); if (!slrt || slrt->magic != SLR_TABLE_MAGIC) return; > + /* Add config information to measure the UEFI memory map */ > + uefi_config = (struct slr_entry_uefi_config *)buf; > + uefi_config->hdr.tag = SLR_ENTRY_UEFI_CONFIG; > + uefi_config->hdr.size = sizeof(*uefi_config) + sizeof(*uefi_entry); > + uefi_config->revision = SLR_UEFI_CONFIG_REVISION; > + uefi_config->nr_entries = 1; > + uefi_entry = (struct slr_uefi_cfg_entry *)(buf + sizeof(*uefi_config)); > + uefi_entry->pcr = 18; > + uefi_entry->cfg = boot_params->efi_info.efi_memmap; > + memmap_hi = boot_params->efi_info.efi_memmap_hi; > + uefi_entry->cfg |= memmap_hi << 32; > + uefi_entry->size = boot_params->efi_info.efi_memmap_size; > + memcpy(&uefi_entry->evt_info[0], "Measured UEFI memory map", > + strlen("Measured UEFI memory map")); > + Drop all of this > + if (slr_add_entry(slrt, (struct slr_entry_hdr *)uefi_config)) if (slr_add_entry(slrt, &uefi_config.hdr)) > + return; > + > + /* Jump through DL stub to initiate Secure Launch */ > + dlinfo = (struct slr_entry_dl_info *) > + slr_next_entry_by_tag(slrt, NULL, SLR_ENTRY_DL_INFO); > + > + asm volatile ("jmp *%%rax" > + : : "a" (dlinfo->dl_handler), "D" (&dlinfo->bl_context)); Fix the prototype and just do dlinfo->dl_handler(&dlinfo->bl_context); unreachable(); So in summary, this becomes static void efi_secure_launch(struct boot_params *boot_params) { static struct slr_entry_uefi_config cfg = { .hdr.tag = SLR_ENTRY_UEFI_CONFIG, .hdr.size = sizeof(cfg), .revision = SLR_UEFI_CONFIG_REVISION, .nr_entries = 1, .entries[0] = { .pcr = 18, .evt_info = "Measured UEFI memory map", }, }; struct slr_entry_dl_info *dlinfo; efi_guid_t guid = SLR_TABLE_GUID; struct slr_table *slrt; /* * The presence of this table indicated a Secure Launch * is being requested. */ slrt = (struct slr_table *)get_efi_config_table(guid); if (!slrt || slrt->magic != SLR_TABLE_MAGIC) return; cfg.entries[0].cfg = boot_params->efi_info.efi_memmap | (u64)boot_params->efi_info.efi_memmap_hi << 32; cfg.entries[0].size = boot_params->efi_info.efi_memmap_size; if (slr_add_entry(slrt, &cfg.hdr)) return; /* Jump through DL stub to initiate Secure Launch */ dlinfo = (struct slr_entry_dl_info *) slr_next_entry_by_tag(slrt, NULL, SLR_ENTRY_DL_INFO); dlinfo->dl_handler(&dlinfo->bl_context); unreachable(); } > +} > + > static void __noreturn enter_kernel(unsigned long kernel_addr, > struct boot_params *boot_params) > { > @@ -934,6 +986,9 @@ void __noreturn efi_stub_entry(efi_handle_t handle, > goto fail; > } > > + /* If a Secure Launch is in progress, this never returns */ if (IS_ENABLED(CONFIG_SECURE_LAUNCH)) > + efi_secure_launch(boot_params); > + > /* > * Call the SEV init code while still running with the firmware's > * GDT/IDT, so #VC exceptions will be handled by EFI. > -- > 2.39.3 >
Hi Ross, kernel test robot noticed the following build errors: [auto build test ERROR on char-misc/char-misc-testing] [also build test ERROR on char-misc/char-misc-next char-misc/char-misc-linus herbert-cryptodev-2.6/master herbert-crypto-2.6/master linus/master v6.8-rc4 next-20240216] [cannot apply to tip/x86/core] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information] url: https://github.com/intel-lab-lkp/linux/commits/Ross-Philipson/x86-boot-Place-kernel_info-at-a-fixed-offset/20240215-064712 base: char-misc/char-misc-testing patch link: https://lore.kernel.org/r/20240214221847.2066632-16-ross.philipson%40oracle.com patch subject: [PATCH v8 15/15] x86: EFI stub DRTM launch support for Secure Launch config: i386-randconfig-052-20240215 (https://download.01.org/0day-ci/archive/20240217/202402171503.kLhNHtkM-lkp@intel.com/config) compiler: clang version 17.0.6 (https://github.com/llvm/llvm-project 6009708b4367171ccdbf4b5905cb6a803753fe18) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240217/202402171503.kLhNHtkM-lkp@intel.com/reproduce) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp@intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202402171503.kLhNHtkM-lkp@intel.com/ All errors (new ones prefixed by >>): >> drivers/firmware/efi/libstub/x86-stub.c:862:18: error: invalid input size for constraint 'a' 862 | : : "a" (dlinfo->dl_handler), "D" (&dlinfo->bl_context)); | ^ 1 error generated. vim +/a +862 drivers/firmware/efi/libstub/x86-stub.c 813 814 static void efi_secure_launch(struct boot_params *boot_params) 815 { 816 struct slr_entry_uefi_config *uefi_config; 817 struct slr_uefi_cfg_entry *uefi_entry; 818 struct slr_entry_dl_info *dlinfo; 819 efi_guid_t guid = SLR_TABLE_GUID; 820 struct slr_table *slrt; 821 u64 memmap_hi; 822 void *table; 823 u8 buf[64] = {0}; 824 825 table = get_efi_config_table(guid); 826 827 /* 828 * The presence of this table indicated a Secure Launch 829 * is being requested. 830 */ 831 if (!table) 832 return; 833 834 slrt = (struct slr_table *)table; 835 836 if (slrt->magic != SLR_TABLE_MAGIC) 837 return; 838 839 /* Add config information to measure the UEFI memory map */ 840 uefi_config = (struct slr_entry_uefi_config *)buf; 841 uefi_config->hdr.tag = SLR_ENTRY_UEFI_CONFIG; 842 uefi_config->hdr.size = sizeof(*uefi_config) + sizeof(*uefi_entry); 843 uefi_config->revision = SLR_UEFI_CONFIG_REVISION; 844 uefi_config->nr_entries = 1; 845 uefi_entry = (struct slr_uefi_cfg_entry *)(buf + sizeof(*uefi_config)); 846 uefi_entry->pcr = 18; 847 uefi_entry->cfg = boot_params->efi_info.efi_memmap; 848 memmap_hi = boot_params->efi_info.efi_memmap_hi; 849 uefi_entry->cfg |= memmap_hi << 32; 850 uefi_entry->size = boot_params->efi_info.efi_memmap_size; 851 memcpy(&uefi_entry->evt_info[0], "Measured UEFI memory map", 852 strlen("Measured UEFI memory map")); 853 854 if (slr_add_entry(slrt, (struct slr_entry_hdr *)uefi_config)) 855 return; 856 857 /* Jump through DL stub to initiate Secure Launch */ 858 dlinfo = (struct slr_entry_dl_info *) 859 slr_next_entry_by_tag(slrt, NULL, SLR_ENTRY_DL_INFO); 860 861 asm volatile ("jmp *%%rax" > 862 : : "a" (dlinfo->dl_handler), "D" (&dlinfo->bl_context)); 863 } 864
Hi Ross, kernel test robot noticed the following build errors: [auto build test ERROR on char-misc/char-misc-testing] [also build test ERROR on char-misc/char-misc-next char-misc/char-misc-linus herbert-cryptodev-2.6/master herbert-crypto-2.6/master linus/master v6.8-rc4 next-20240216] [cannot apply to tip/x86/core] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information] url: https://github.com/intel-lab-lkp/linux/commits/Ross-Philipson/x86-boot-Place-kernel_info-at-a-fixed-offset/20240215-064712 base: char-misc/char-misc-testing patch link: https://lore.kernel.org/r/20240214221847.2066632-16-ross.philipson%40oracle.com patch subject: [PATCH v8 15/15] x86: EFI stub DRTM launch support for Secure Launch config: i386-allmodconfig (https://download.01.org/0day-ci/archive/20240218/202402180324.a3PqEegg-lkp@intel.com/config) compiler: gcc-12 (Debian 12.2.0-14) 12.2.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240218/202402180324.a3PqEegg-lkp@intel.com/reproduce) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp@intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202402180324.a3PqEegg-lkp@intel.com/ All errors (new ones prefixed by >>): In function 'efi_secure_launch', inlined from 'efi_stub_entry' at drivers/firmware/efi/libstub/x86-stub.c:990:2: >> drivers/firmware/efi/libstub/x86-stub.c:861:9: error: inconsistent operand constraints in an 'asm' 861 | asm volatile ("jmp *%%rax" | ^~~ vim +/asm +861 drivers/firmware/efi/libstub/x86-stub.c 813 814 static void efi_secure_launch(struct boot_params *boot_params) 815 { 816 struct slr_entry_uefi_config *uefi_config; 817 struct slr_uefi_cfg_entry *uefi_entry; 818 struct slr_entry_dl_info *dlinfo; 819 efi_guid_t guid = SLR_TABLE_GUID; 820 struct slr_table *slrt; 821 u64 memmap_hi; 822 void *table; 823 u8 buf[64] = {0}; 824 825 table = get_efi_config_table(guid); 826 827 /* 828 * The presence of this table indicated a Secure Launch 829 * is being requested. 830 */ 831 if (!table) 832 return; 833 834 slrt = (struct slr_table *)table; 835 836 if (slrt->magic != SLR_TABLE_MAGIC) 837 return; 838 839 /* Add config information to measure the UEFI memory map */ 840 uefi_config = (struct slr_entry_uefi_config *)buf; 841 uefi_config->hdr.tag = SLR_ENTRY_UEFI_CONFIG; 842 uefi_config->hdr.size = sizeof(*uefi_config) + sizeof(*uefi_entry); 843 uefi_config->revision = SLR_UEFI_CONFIG_REVISION; 844 uefi_config->nr_entries = 1; 845 uefi_entry = (struct slr_uefi_cfg_entry *)(buf + sizeof(*uefi_config)); 846 uefi_entry->pcr = 18; 847 uefi_entry->cfg = boot_params->efi_info.efi_memmap; 848 memmap_hi = boot_params->efi_info.efi_memmap_hi; 849 uefi_entry->cfg |= memmap_hi << 32; 850 uefi_entry->size = boot_params->efi_info.efi_memmap_size; 851 memcpy(&uefi_entry->evt_info[0], "Measured UEFI memory map", 852 strlen("Measured UEFI memory map")); 853 854 if (slr_add_entry(slrt, (struct slr_entry_hdr *)uefi_config)) 855 return; 856 857 /* Jump through DL stub to initiate Secure Launch */ 858 dlinfo = (struct slr_entry_dl_info *) 859 slr_next_entry_by_tag(slrt, NULL, SLR_ENTRY_DL_INFO); 860 > 861 asm volatile ("jmp *%%rax" 862 : : "a" (dlinfo->dl_handler), "D" (&dlinfo->bl_context)); 863 } 864
On 2/15/24 1:01 AM, Ard Biesheuvel wrote: > On Wed, 14 Feb 2024 at 23:32, Ross Philipson <ross.philipson@oracle.com> wrote: >> >> This support allows the DRTM launch to be initiated after an EFI stub >> launch of the Linux kernel is done. This is accomplished by providing >> a handler to jump to when a Secure Launch is in progress. This has to be >> called after the EFI stub does Exit Boot Services. >> >> Signed-off-by: Ross Philipson <ross.philipson@oracle.com> >> --- >> drivers/firmware/efi/libstub/x86-stub.c | 55 +++++++++++++++++++++++++ >> 1 file changed, 55 insertions(+) >> >> diff --git a/drivers/firmware/efi/libstub/x86-stub.c b/drivers/firmware/efi/libstub/x86-stub.c >> index 0d510c9a06a4..4df2cf539194 100644 >> --- a/drivers/firmware/efi/libstub/x86-stub.c >> +++ b/drivers/firmware/efi/libstub/x86-stub.c >> @@ -9,6 +9,7 @@ >> #include <linux/efi.h> >> #include <linux/pci.h> >> #include <linux/stddef.h> >> +#include <linux/slr_table.h> >> >> #include <asm/efi.h> >> #include <asm/e820/types.h> >> @@ -810,6 +811,57 @@ static efi_status_t efi_decompress_kernel(unsigned long *kernel_entry) >> return EFI_SUCCESS; >> } >> >> +static void efi_secure_launch(struct boot_params *boot_params) >> +{ >> + struct slr_entry_uefi_config *uefi_config; >> + struct slr_uefi_cfg_entry *uefi_entry; >> + struct slr_entry_dl_info *dlinfo; >> + efi_guid_t guid = SLR_TABLE_GUID; >> + struct slr_table *slrt; >> + u64 memmap_hi; >> + void *table; >> + u8 buf[64] = {0}; >> + > > If you add a flex array to slr_entry_uefi_config as I suggested in > response to the other patch, we could simplify this substantially I feel like there is some reason why we did not use flex arrays. We were talking and we seem to remember we used to use them and someone asked us to remove them. We are still looking into it. But if we can go back to them, I will take all the changes you recommended here. Thanks Ross > > static struct slr_entry_uefi_config cfg = { > .hdr.tag = SLR_ENTRY_UEFI_CONFIG, > .hdr.size = sizeof(cfg), > .revision = SLR_UEFI_CONFIG_REVISION, > .nr_entries = 1, > .entries[0] = { > .pcr = 18, > .evt_info = "Measured UEFI memory map", > }, > }; > > cfg.entries[0].cfg = boot_params->efi_info.efi_memmap | > (u64)boot_params->efi_info.efi_memmap_hi << 32; > cfg.entries[0].size = boot_params->efi_info.efi_memmap_size; > > > >> + table = get_efi_config_table(guid); >> + >> + /* >> + * The presence of this table indicated a Secure Launch >> + * is being requested. >> + */ >> + if (!table) >> + return; >> + >> + slrt = (struct slr_table *)table; >> + >> + if (slrt->magic != SLR_TABLE_MAGIC) >> + return; >> + > > slrt = (struct slr_table *)get_efi_config_table(guid); > if (!slrt || slrt->magic != SLR_TABLE_MAGIC) > return; > >> + /* Add config information to measure the UEFI memory map */ >> + uefi_config = (struct slr_entry_uefi_config *)buf; >> + uefi_config->hdr.tag = SLR_ENTRY_UEFI_CONFIG; >> + uefi_config->hdr.size = sizeof(*uefi_config) + sizeof(*uefi_entry); >> + uefi_config->revision = SLR_UEFI_CONFIG_REVISION; >> + uefi_config->nr_entries = 1; >> + uefi_entry = (struct slr_uefi_cfg_entry *)(buf + sizeof(*uefi_config)); >> + uefi_entry->pcr = 18; >> + uefi_entry->cfg = boot_params->efi_info.efi_memmap; >> + memmap_hi = boot_params->efi_info.efi_memmap_hi; >> + uefi_entry->cfg |= memmap_hi << 32; >> + uefi_entry->size = boot_params->efi_info.efi_memmap_size; >> + memcpy(&uefi_entry->evt_info[0], "Measured UEFI memory map", >> + strlen("Measured UEFI memory map")); >> + > > Drop all of this > >> + if (slr_add_entry(slrt, (struct slr_entry_hdr *)uefi_config)) > > if (slr_add_entry(slrt, &uefi_config.hdr)) > > >> + return; >> + >> + /* Jump through DL stub to initiate Secure Launch */ >> + dlinfo = (struct slr_entry_dl_info *) >> + slr_next_entry_by_tag(slrt, NULL, SLR_ENTRY_DL_INFO); >> + >> + asm volatile ("jmp *%%rax" >> + : : "a" (dlinfo->dl_handler), "D" (&dlinfo->bl_context)); > > Fix the prototype and just do > > dlinfo->dl_handler(&dlinfo->bl_context); > unreachable(); > > > So in summary, this becomes > > static void efi_secure_launch(struct boot_params *boot_params) > { > static struct slr_entry_uefi_config cfg = { > .hdr.tag = SLR_ENTRY_UEFI_CONFIG, > .hdr.size = sizeof(cfg), > .revision = SLR_UEFI_CONFIG_REVISION, > .nr_entries = 1, > .entries[0] = { > .pcr = 18, > .evt_info = "Measured UEFI memory map", > }, > }; > struct slr_entry_dl_info *dlinfo; > efi_guid_t guid = SLR_TABLE_GUID; > struct slr_table *slrt; > > /* > * The presence of this table indicated a Secure Launch > * is being requested. > */ > slrt = (struct slr_table *)get_efi_config_table(guid); > if (!slrt || slrt->magic != SLR_TABLE_MAGIC) > return; > > cfg.entries[0].cfg = boot_params->efi_info.efi_memmap | > (u64)boot_params->efi_info.efi_memmap_hi << 32; > cfg.entries[0].size = boot_params->efi_info.efi_memmap_size; > > if (slr_add_entry(slrt, &cfg.hdr)) > return; > > /* Jump through DL stub to initiate Secure Launch */ > dlinfo = (struct slr_entry_dl_info *) > slr_next_entry_by_tag(slrt, NULL, SLR_ENTRY_DL_INFO); > > dlinfo->dl_handler(&dlinfo->bl_context); > > unreachable(); > } > > >> +} >> + >> static void __noreturn enter_kernel(unsigned long kernel_addr, >> struct boot_params *boot_params) >> { >> @@ -934,6 +986,9 @@ void __noreturn efi_stub_entry(efi_handle_t handle, >> goto fail; >> } >> >> + /* If a Secure Launch is in progress, this never returns */ > > if (IS_ENABLED(CONFIG_SECURE_LAUNCH)) > >> + efi_secure_launch(boot_params); >> + >> /* >> * Call the SEV init code while still running with the firmware's >> * GDT/IDT, so #VC exceptions will be handled by EFI. >> -- >> 2.39.3 >> >
On February 21, 2024 12:17:30 PM PST, ross.philipson@oracle.com wrote: >On 2/15/24 1:01 AM, Ard Biesheuvel wrote: >> On Wed, 14 Feb 2024 at 23:32, Ross Philipson <ross.philipson@oracle.com> wrote: >>> >>> This support allows the DRTM launch to be initiated after an EFI stub >>> launch of the Linux kernel is done. This is accomplished by providing >>> a handler to jump to when a Secure Launch is in progress. This has to be >>> called after the EFI stub does Exit Boot Services. >>> >>> Signed-off-by: Ross Philipson <ross.philipson@oracle.com> >>> --- >>> drivers/firmware/efi/libstub/x86-stub.c | 55 +++++++++++++++++++++++++ >>> 1 file changed, 55 insertions(+) >>> >>> diff --git a/drivers/firmware/efi/libstub/x86-stub.c b/drivers/firmware/efi/libstub/x86-stub.c >>> index 0d510c9a06a4..4df2cf539194 100644 >>> --- a/drivers/firmware/efi/libstub/x86-stub.c >>> +++ b/drivers/firmware/efi/libstub/x86-stub.c >>> @@ -9,6 +9,7 @@ >>> #include <linux/efi.h> >>> #include <linux/pci.h> >>> #include <linux/stddef.h> >>> +#include <linux/slr_table.h> >>> >>> #include <asm/efi.h> >>> #include <asm/e820/types.h> >>> @@ -810,6 +811,57 @@ static efi_status_t efi_decompress_kernel(unsigned long *kernel_entry) >>> return EFI_SUCCESS; >>> } >>> >>> +static void efi_secure_launch(struct boot_params *boot_params) >>> +{ >>> + struct slr_entry_uefi_config *uefi_config; >>> + struct slr_uefi_cfg_entry *uefi_entry; >>> + struct slr_entry_dl_info *dlinfo; >>> + efi_guid_t guid = SLR_TABLE_GUID; >>> + struct slr_table *slrt; >>> + u64 memmap_hi; >>> + void *table; >>> + u8 buf[64] = {0}; >>> + >> >> If you add a flex array to slr_entry_uefi_config as I suggested in >> response to the other patch, we could simplify this substantially > >I feel like there is some reason why we did not use flex arrays. We were talking and we seem to remember we used to use them and someone asked us to remove them. We are still looking into it. But if we can go back to them, I will take all the changes you recommended here. > >Thanks >Ross > >> >> static struct slr_entry_uefi_config cfg = { >> .hdr.tag = SLR_ENTRY_UEFI_CONFIG, >> .hdr.size = sizeof(cfg), >> .revision = SLR_UEFI_CONFIG_REVISION, >> .nr_entries = 1, >> .entries[0] = { >> .pcr = 18, >> .evt_info = "Measured UEFI memory map", >> }, >> }; >> >> cfg.entries[0].cfg = boot_params->efi_info.efi_memmap | >> (u64)boot_params->efi_info.efi_memmap_hi << 32; >> cfg.entries[0].size = boot_params->efi_info.efi_memmap_size; >> >> >> >>> + table = get_efi_config_table(guid); >>> + >>> + /* >>> + * The presence of this table indicated a Secure Launch >>> + * is being requested. >>> + */ >>> + if (!table) >>> + return; >>> + >>> + slrt = (struct slr_table *)table; >>> + >>> + if (slrt->magic != SLR_TABLE_MAGIC) >>> + return; >>> + >> >> slrt = (struct slr_table *)get_efi_config_table(guid); >> if (!slrt || slrt->magic != SLR_TABLE_MAGIC) >> return; >> >>> + /* Add config information to measure the UEFI memory map */ >>> + uefi_config = (struct slr_entry_uefi_config *)buf; >>> + uefi_config->hdr.tag = SLR_ENTRY_UEFI_CONFIG; >>> + uefi_config->hdr.size = sizeof(*uefi_config) + sizeof(*uefi_entry); >>> + uefi_config->revision = SLR_UEFI_CONFIG_REVISION; >>> + uefi_config->nr_entries = 1; >>> + uefi_entry = (struct slr_uefi_cfg_entry *)(buf + sizeof(*uefi_config)); >>> + uefi_entry->pcr = 18; >>> + uefi_entry->cfg = boot_params->efi_info.efi_memmap; >>> + memmap_hi = boot_params->efi_info.efi_memmap_hi; >>> + uefi_entry->cfg |= memmap_hi << 32; >>> + uefi_entry->size = boot_params->efi_info.efi_memmap_size; >>> + memcpy(&uefi_entry->evt_info[0], "Measured UEFI memory map", >>> + strlen("Measured UEFI memory map")); >>> + >> >> Drop all of this >> >>> + if (slr_add_entry(slrt, (struct slr_entry_hdr *)uefi_config)) >> >> if (slr_add_entry(slrt, &uefi_config.hdr)) >> >> >>> + return; >>> + >>> + /* Jump through DL stub to initiate Secure Launch */ >>> + dlinfo = (struct slr_entry_dl_info *) >>> + slr_next_entry_by_tag(slrt, NULL, SLR_ENTRY_DL_INFO); >>> + >>> + asm volatile ("jmp *%%rax" >>> + : : "a" (dlinfo->dl_handler), "D" (&dlinfo->bl_context)); >> >> Fix the prototype and just do >> >> dlinfo->dl_handler(&dlinfo->bl_context); >> unreachable(); >> >> >> So in summary, this becomes >> >> static void efi_secure_launch(struct boot_params *boot_params) >> { >> static struct slr_entry_uefi_config cfg = { >> .hdr.tag = SLR_ENTRY_UEFI_CONFIG, >> .hdr.size = sizeof(cfg), >> .revision = SLR_UEFI_CONFIG_REVISION, >> .nr_entries = 1, >> .entries[0] = { >> .pcr = 18, >> .evt_info = "Measured UEFI memory map", >> }, >> }; >> struct slr_entry_dl_info *dlinfo; >> efi_guid_t guid = SLR_TABLE_GUID; >> struct slr_table *slrt; >> >> /* >> * The presence of this table indicated a Secure Launch >> * is being requested. >> */ >> slrt = (struct slr_table *)get_efi_config_table(guid); >> if (!slrt || slrt->magic != SLR_TABLE_MAGIC) >> return; >> >> cfg.entries[0].cfg = boot_params->efi_info.efi_memmap | >> (u64)boot_params->efi_info.efi_memmap_hi << 32; >> cfg.entries[0].size = boot_params->efi_info.efi_memmap_size; >> >> if (slr_add_entry(slrt, &cfg.hdr)) >> return; >> >> /* Jump through DL stub to initiate Secure Launch */ >> dlinfo = (struct slr_entry_dl_info *) >> slr_next_entry_by_tag(slrt, NULL, SLR_ENTRY_DL_INFO); >> >> dlinfo->dl_handler(&dlinfo->bl_context); >> >> unreachable(); >> } >> >> >>> +} >>> + >>> static void __noreturn enter_kernel(unsigned long kernel_addr, >>> struct boot_params *boot_params) >>> { >>> @@ -934,6 +986,9 @@ void __noreturn efi_stub_entry(efi_handle_t handle, >>> goto fail; >>> } >>> >>> + /* If a Secure Launch is in progress, this never returns */ >> >> if (IS_ENABLED(CONFIG_SECURE_LAUNCH)) >> >>> + efi_secure_launch(boot_params); >>> + >>> /* >>> * Call the SEV init code while still running with the firmware's >>> * GDT/IDT, so #VC exceptions will be handled by EFI. >>> -- >>> 2.39.3 >>> >> > Linux kernel code doesn't use VLAs because of the limited stack size, and VLAs or alloca() makes stack size tracking impossible. Although this technically speaking runs in a different environment, it is easier to enforce the constraint globally.
On Wed, 21 Feb 2024 at 21:37, H. Peter Anvin <hpa@zytor.com> wrote: > > On February 21, 2024 12:17:30 PM PST, ross.philipson@oracle.com wrote: > >On 2/15/24 1:01 AM, Ard Biesheuvel wrote: > >> On Wed, 14 Feb 2024 at 23:32, Ross Philipson <ross.philipson@oracle.com> wrote: > >>> > >>> This support allows the DRTM launch to be initiated after an EFI stub > >>> launch of the Linux kernel is done. This is accomplished by providing > >>> a handler to jump to when a Secure Launch is in progress. This has to be > >>> called after the EFI stub does Exit Boot Services. > >>> > >>> Signed-off-by: Ross Philipson <ross.philipson@oracle.com> > >>> --- > >>> drivers/firmware/efi/libstub/x86-stub.c | 55 +++++++++++++++++++++++++ > >>> 1 file changed, 55 insertions(+) > >>> > >>> diff --git a/drivers/firmware/efi/libstub/x86-stub.c b/drivers/firmware/efi/libstub/x86-stub.c > >>> index 0d510c9a06a4..4df2cf539194 100644 > >>> --- a/drivers/firmware/efi/libstub/x86-stub.c > >>> +++ b/drivers/firmware/efi/libstub/x86-stub.c > >>> @@ -9,6 +9,7 @@ > >>> #include <linux/efi.h> > >>> #include <linux/pci.h> > >>> #include <linux/stddef.h> > >>> +#include <linux/slr_table.h> > >>> > >>> #include <asm/efi.h> > >>> #include <asm/e820/types.h> > >>> @@ -810,6 +811,57 @@ static efi_status_t efi_decompress_kernel(unsigned long *kernel_entry) > >>> return EFI_SUCCESS; > >>> } > >>> > >>> +static void efi_secure_launch(struct boot_params *boot_params) > >>> +{ > >>> + struct slr_entry_uefi_config *uefi_config; > >>> + struct slr_uefi_cfg_entry *uefi_entry; > >>> + struct slr_entry_dl_info *dlinfo; > >>> + efi_guid_t guid = SLR_TABLE_GUID; > >>> + struct slr_table *slrt; > >>> + u64 memmap_hi; > >>> + void *table; > >>> + u8 buf[64] = {0}; > >>> + > >> > >> If you add a flex array to slr_entry_uefi_config as I suggested in > >> response to the other patch, we could simplify this substantially > > > >I feel like there is some reason why we did not use flex arrays. We were talking and we seem to remember we used to use them and someone asked us to remove them. We are still looking into it. But if we can go back to them, I will take all the changes you recommended here. > > > > Linux kernel code doesn't use VLAs because of the limited stack size, and VLAs or alloca() makes stack size tracking impossible. Although this technically speaking runs in a different environment, it is easier to enforce the constraint globally. Flex array != VLA VLAs were phased out because of this reason (and VLAISs [VLAs in structs] were phased out before that because they are a GNU extension and not supported by Clang) Today, VLAs are not supported anywhere in the kernel. Flex arrays are widely used in the kernel. A flex array is a trailing array of unspecified size in a struct that makes the entire *type* have a variable size. But that does not make them VLAs (or VLAISs) - a VLA is a stack allocated *variable* whose size is based on a function parameter. Instances of types containing flex arrays can be allocated statically, or dynamically on the heap. This is common practice in the kernel, and even supported by instrumentation to help the compiler track the runtime size and flag overruns. We are even in the process of adding compiler support to annotate struct members as carrying the number of elements in an associated flex arrays, to improve the coverage of the instrumentation. I am not asking for a VLA here, only a flex array.
diff --git a/drivers/firmware/efi/libstub/x86-stub.c b/drivers/firmware/efi/libstub/x86-stub.c index 0d510c9a06a4..4df2cf539194 100644 --- a/drivers/firmware/efi/libstub/x86-stub.c +++ b/drivers/firmware/efi/libstub/x86-stub.c @@ -9,6 +9,7 @@ #include <linux/efi.h> #include <linux/pci.h> #include <linux/stddef.h> +#include <linux/slr_table.h> #include <asm/efi.h> #include <asm/e820/types.h> @@ -810,6 +811,57 @@ static efi_status_t efi_decompress_kernel(unsigned long *kernel_entry) return EFI_SUCCESS; } +static void efi_secure_launch(struct boot_params *boot_params) +{ + struct slr_entry_uefi_config *uefi_config; + struct slr_uefi_cfg_entry *uefi_entry; + struct slr_entry_dl_info *dlinfo; + efi_guid_t guid = SLR_TABLE_GUID; + struct slr_table *slrt; + u64 memmap_hi; + void *table; + u8 buf[64] = {0}; + + table = get_efi_config_table(guid); + + /* + * The presence of this table indicated a Secure Launch + * is being requested. + */ + if (!table) + return; + + slrt = (struct slr_table *)table; + + if (slrt->magic != SLR_TABLE_MAGIC) + return; + + /* Add config information to measure the UEFI memory map */ + uefi_config = (struct slr_entry_uefi_config *)buf; + uefi_config->hdr.tag = SLR_ENTRY_UEFI_CONFIG; + uefi_config->hdr.size = sizeof(*uefi_config) + sizeof(*uefi_entry); + uefi_config->revision = SLR_UEFI_CONFIG_REVISION; + uefi_config->nr_entries = 1; + uefi_entry = (struct slr_uefi_cfg_entry *)(buf + sizeof(*uefi_config)); + uefi_entry->pcr = 18; + uefi_entry->cfg = boot_params->efi_info.efi_memmap; + memmap_hi = boot_params->efi_info.efi_memmap_hi; + uefi_entry->cfg |= memmap_hi << 32; + uefi_entry->size = boot_params->efi_info.efi_memmap_size; + memcpy(&uefi_entry->evt_info[0], "Measured UEFI memory map", + strlen("Measured UEFI memory map")); + + if (slr_add_entry(slrt, (struct slr_entry_hdr *)uefi_config)) + return; + + /* Jump through DL stub to initiate Secure Launch */ + dlinfo = (struct slr_entry_dl_info *) + slr_next_entry_by_tag(slrt, NULL, SLR_ENTRY_DL_INFO); + + asm volatile ("jmp *%%rax" + : : "a" (dlinfo->dl_handler), "D" (&dlinfo->bl_context)); +} + static void __noreturn enter_kernel(unsigned long kernel_addr, struct boot_params *boot_params) { @@ -934,6 +986,9 @@ void __noreturn efi_stub_entry(efi_handle_t handle, goto fail; } + /* If a Secure Launch is in progress, this never returns */ + efi_secure_launch(boot_params); + /* * Call the SEV init code while still running with the firmware's * GDT/IDT, so #VC exceptions will be handled by EFI.