From: Ard Biesheuvel <ardb@kernel.org> To: Ross Philipson <ross.philipson@oracle.com> Cc: 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, dpsmith@apertussolutions.com, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, hpa@zytor.com, dave.hansen@linux.intel.com, 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: Re: [PATCH v8 15/15] x86: EFI stub DRTM launch support for Secure Launch Date: Thu, 15 Feb 2024 10:01:03 +0100 [thread overview] Message-ID: <CAMj1kXF3k_c4Wn9GU+NC_+_aYfDpAzAUnfR=A4L_T+re1H3G=w@mail.gmail.com> (raw) In-Reply-To: <20240214221847.2066632-16-ross.philipson@oracle.com> 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 >
WARNING: multiple messages have this Message-ID (diff)
From: Ard Biesheuvel <ardb@kernel.org> To: Ross Philipson <ross.philipson@oracle.com> Cc: 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, dpsmith@apertussolutions.com, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, hpa@zytor.com, dave.hansen@linux.intel.com, 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: Re: [PATCH v8 15/15] x86: EFI stub DRTM launch support for Secure Launch Date: Thu, 15 Feb 2024 10:01:03 +0100 [thread overview] Message-ID: <CAMj1kXF3k_c4Wn9GU+NC_+_aYfDpAzAUnfR=A4L_T+re1H3G=w@mail.gmail.com> (raw) In-Reply-To: <20240214221847.2066632-16-ross.philipson@oracle.com> 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 > _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2024-02-15 9:01 UTC|newest] Thread overview: 116+ messages / expand[flat|nested] mbox.gz Atom feed top 2024-02-14 22:18 [PATCH v8 00/15] x86: Trenchboot secure dynamic launch Linux kernel support Ross Philipson 2024-02-14 22:18 ` Ross Philipson 2024-02-14 22:18 ` [PATCH v8 01/15] x86/boot: Place kernel_info at a fixed offset Ross Philipson 2024-02-14 22:18 ` Ross Philipson 2024-02-15 7:56 ` Ard Biesheuvel 2024-02-15 7:56 ` Ard Biesheuvel 2024-02-15 10:56 ` Daniel Kiper 2024-02-15 10:56 ` Daniel Kiper 2024-03-21 13:45 ` Daniel P. Smith 2024-03-21 13:45 ` Daniel P. Smith 2024-03-22 14:18 ` H. Peter Anvin 2024-03-22 14:18 ` H. Peter Anvin 2024-03-23 1:33 ` Daniel P. Smith 2024-03-23 1:33 ` Daniel P. Smith 2024-02-14 22:18 ` [PATCH v8 02/15] Documentation/x86: Secure Launch kernel documentation Ross Philipson 2024-02-14 22:18 ` Ross Philipson 2024-02-14 22:18 ` [PATCH v8 03/15] x86: Secure Launch Kconfig Ross Philipson 2024-02-14 22:18 ` Ross Philipson 2024-02-15 7:59 ` Ard Biesheuvel 2024-02-15 7:59 ` Ard Biesheuvel 2024-02-15 22:20 ` ross.philipson 2024-02-15 22:20 ` ross.philipson 2024-02-14 22:18 ` [PATCH v8 04/15] x86: Secure Launch Resource Table header file Ross Philipson 2024-02-14 22:18 ` Ross Philipson 2024-02-15 8:08 ` Ard Biesheuvel 2024-02-15 8:08 ` Ard Biesheuvel 2024-02-22 2:03 ` Andrew Cooper 2024-02-22 2:03 ` Andrew Cooper 2024-02-22 2:10 ` ross.philipson 2024-02-22 2:10 ` ross.philipson 2024-02-22 17:49 ` ross.philipson 2024-02-22 17:49 ` ross.philipson 2024-03-29 22:38 ` Kim Phillips 2024-03-29 22:38 ` Kim Phillips 2024-03-29 22:38 ` Kim Phillips 2024-03-29 22:38 ` Kim Phillips 2024-03-29 22:38 ` Kim Phillips 2024-03-29 22:38 ` Kim Phillips 2024-04-01 18:25 ` ross.philipson 2024-04-01 18:25 ` ross.philipson 2024-02-14 22:18 ` [PATCH v8 05/15] x86: Secure Launch main " Ross Philipson 2024-02-14 22:18 ` Ross Philipson 2024-02-14 22:18 ` [PATCH v8 06/15] x86: Add early SHA support for Secure Launch early measurements Ross Philipson 2024-02-14 22:18 ` Ross Philipson 2024-02-15 8:17 ` Ard Biesheuvel 2024-02-15 8:17 ` Ard Biesheuvel 2024-02-22 3:04 ` Andrew Cooper 2024-02-22 3:04 ` Andrew Cooper 2024-02-22 9:34 ` Ard Biesheuvel 2024-02-22 9:34 ` Ard Biesheuvel 2024-02-22 12:30 ` Andrew Cooper 2024-02-22 12:30 ` Andrew Cooper 2024-02-23 9:27 ` Ard Biesheuvel 2024-02-23 9:27 ` Ard Biesheuvel 2024-02-23 16:42 ` Andrew Cooper 2024-02-23 16:42 ` Andrew Cooper 2024-02-23 17:54 ` Eric Biggers 2024-02-23 17:54 ` Eric Biggers 2024-02-23 18:20 ` Andrew Cooper 2024-02-23 18:20 ` Andrew Cooper 2024-02-23 18:30 ` Eric Biggers 2024-02-23 18:30 ` Eric Biggers 2024-04-03 16:32 ` Andy Lutomirski 2024-04-03 16:32 ` Andy Lutomirski 2024-04-03 23:56 ` Eric Biggers 2024-04-03 23:56 ` Eric Biggers 2024-04-04 4:55 ` ross.philipson 2024-04-04 4:55 ` ross.philipson 2024-04-04 14:55 ` Jarkko Sakkinen 2024-04-04 14:55 ` Jarkko Sakkinen 2024-02-14 22:18 ` [PATCH v8 07/15] x86: Secure Launch kernel early boot stub Ross Philipson 2024-02-14 22:18 ` Ross Philipson 2024-02-15 8:29 ` Ard Biesheuvel 2024-02-15 8:29 ` Ard Biesheuvel 2024-02-15 22:26 ` ross.philipson 2024-02-15 22:26 ` ross.philipson 2024-02-14 22:18 ` [PATCH v8 08/15] x86: Secure Launch kernel late " Ross Philipson 2024-02-14 22:18 ` Ross Philipson 2024-02-14 22:18 ` [PATCH v8 09/15] x86: Secure Launch SMP bringup support Ross Philipson 2024-02-14 22:18 ` Ross Philipson 2024-02-14 22:18 ` [PATCH v8 10/15] kexec: Secure Launch kexec SEXIT support Ross Philipson 2024-02-14 22:18 ` Ross Philipson 2024-02-14 22:18 ` [PATCH v8 11/15] reboot: Secure Launch SEXIT support on reboot paths Ross Philipson 2024-02-14 22:18 ` Ross Philipson 2024-02-14 22:18 ` [PATCH v8 12/15] tpm: Add ability to set the preferred locality the TPM chip uses Ross Philipson 2024-02-14 22:18 ` Ross Philipson 2024-02-14 22:18 ` [PATCH v8 13/15] tpm: Add sysfs interface to allow setting and querying the preferred locality Ross Philipson 2024-02-14 22:18 ` Ross Philipson 2024-02-14 22:18 ` [PATCH v8 14/15] x86: Secure Launch late initcall platform module Ross Philipson 2024-02-14 22:18 ` Ross Philipson 2024-02-15 8:40 ` Ard Biesheuvel 2024-02-15 8:40 ` Ard Biesheuvel 2024-02-22 13:57 ` Daniel P. Smith 2024-02-22 13:57 ` Daniel P. Smith 2024-02-23 9:36 ` Ard Biesheuvel 2024-02-23 9:36 ` Ard Biesheuvel 2024-03-21 14:11 ` Daniel P. Smith 2024-03-21 14:11 ` Daniel P. Smith 2024-02-16 1:53 ` kernel test robot 2024-02-16 1:53 ` kernel test robot 2024-02-17 7:53 ` kernel test robot 2024-02-17 7:53 ` kernel test robot 2024-02-14 22:18 ` [PATCH v8 15/15] x86: EFI stub DRTM launch support for Secure Launch Ross Philipson 2024-02-14 22:18 ` Ross Philipson 2024-02-15 9:01 ` Ard Biesheuvel [this message] 2024-02-15 9:01 ` Ard Biesheuvel 2024-02-21 20:17 ` ross.philipson 2024-02-21 20:17 ` ross.philipson 2024-02-21 20:37 ` H. Peter Anvin 2024-02-21 20:37 ` H. Peter Anvin 2024-02-21 23:24 ` Ard Biesheuvel 2024-02-21 23:24 ` Ard Biesheuvel 2024-02-17 7:31 ` kernel test robot 2024-02-17 7:31 ` kernel test robot 2024-02-17 20:06 ` kernel test robot 2024-02-17 20:06 ` kernel test robot
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CAMj1kXF3k_c4Wn9GU+NC_+_aYfDpAzAUnfR=A4L_T+re1H3G=w@mail.gmail.com' \ --to=ardb@kernel.org \ --cc=James.Bottomley@hansenpartnership.com \ --cc=bp@alien8.de \ --cc=dave.hansen@linux.intel.com \ --cc=davem@davemloft.net \ --cc=dpsmith@apertussolutions.com \ --cc=herbert@gondor.apana.org.au \ --cc=hpa@zytor.com \ --cc=jarkko@kernel.org \ --cc=jgg@ziepe.ca \ --cc=kanth.ghatraju@oracle.com \ --cc=kexec@lists.infradead.org \ --cc=linux-crypto@vger.kernel.org \ --cc=linux-doc@vger.kernel.org \ --cc=linux-efi@vger.kernel.org \ --cc=linux-integrity@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=luto@amacapital.net \ --cc=mingo@redhat.com \ --cc=mjg59@srcf.ucam.org \ --cc=nivedita@alum.mit.edu \ --cc=peterhuewe@gmx.de \ --cc=ross.philipson@oracle.com \ --cc=tglx@linutronix.de \ --cc=trenchboot-devel@googlegroups.com \ --cc=x86@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.