| Message ID | 20231110222751.219836-11-ross.philipson@oracle.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | x86: Trenchboot secure dynamic launch Linux kernel support | expand |
On Fri, Nov 10, 2023, Ross Philipson wrote: > Prior to running the next kernel via kexec, the Secure Launch code > closes down private SMX resources and does an SEXIT. This allows the > next kernel to start normally without any issues starting the APs etc. > > Signed-off-by: Ross Philipson <ross.philipson@oracle.com> > --- > arch/x86/kernel/slaunch.c | 73 +++++++++++++++++++++++++++++++++++++++ > kernel/kexec_core.c | 4 +++ > 2 files changed, 77 insertions(+) > > diff --git a/arch/x86/kernel/slaunch.c b/arch/x86/kernel/slaunch.c > index cd5aa34e395c..32b0c24a6484 100644 > --- a/arch/x86/kernel/slaunch.c > +++ b/arch/x86/kernel/slaunch.c > @@ -523,3 +523,76 @@ void __init slaunch_setup_txt(void) > > pr_info("Intel TXT setup complete\n"); > } > + > +static inline void smx_getsec_sexit(void) > +{ > + asm volatile (".byte 0x0f,0x37\n" > + : : "a" (SMX_X86_GETSEC_SEXIT)); SMX has been around for what, two decades? Is open coding getsec actually necessary? > + /* Disable SMX mode */ Heh, the code and the comment don't really agree. I'm guessing the intent of the comment is referring to leaving the measured environment, but it looks odd. If manually setting SMXE is necessary, I'd just delete this comment, or maybe move it to above SEXIT. > + cr4_set_bits(X86_CR4_SMXE); Is it actually legal to clear CR4.SMXE while post-SENTER? I don't see anything in the SDM that says it's illegal, but allowing software to clear SMXE in that case seems all kinds of odd. > + > + /* Do the SEXIT SMX operation */ > + smx_getsec_sexit(); > + > + pr_info("TXT SEXIT complete.\n"); > +}
On 11/10/23 3:41 PM, Sean Christopherson wrote: > On Fri, Nov 10, 2023, Ross Philipson wrote: >> Prior to running the next kernel via kexec, the Secure Launch code >> closes down private SMX resources and does an SEXIT. This allows the >> next kernel to start normally without any issues starting the APs etc. >> >> Signed-off-by: Ross Philipson <ross.philipson@oracle.com> >> --- >> arch/x86/kernel/slaunch.c | 73 +++++++++++++++++++++++++++++++++++++++ >> kernel/kexec_core.c | 4 +++ >> 2 files changed, 77 insertions(+) >> >> diff --git a/arch/x86/kernel/slaunch.c b/arch/x86/kernel/slaunch.c >> index cd5aa34e395c..32b0c24a6484 100644 >> --- a/arch/x86/kernel/slaunch.c >> +++ b/arch/x86/kernel/slaunch.c >> @@ -523,3 +523,76 @@ void __init slaunch_setup_txt(void) >> >> pr_info("Intel TXT setup complete\n"); >> } >> + >> +static inline void smx_getsec_sexit(void) >> +{ >> + asm volatile (".byte 0x0f,0x37\n" >> + : : "a" (SMX_X86_GETSEC_SEXIT)); > > SMX has been around for what, two decades? Is open coding getsec actually necessary? There were some older gcc compilers that still did not like the getsec mnemonic. Perhaps they are old enough now where they don't matter any longer. I will check on that... > >> + /* Disable SMX mode */ > > Heh, the code and the comment don't really agree. I'm guessing the intent of the > comment is referring to leaving the measured environment, but it looks odd. If > manually setting SMXE is necessary, I'd just delete this comment, or maybe move > it to above SEXIT. I will look it over and see what makes sense. > >> + cr4_set_bits(X86_CR4_SMXE); > > Is it actually legal to clear CR4.SMXE while post-SENTER? I don't see anything > in the SDM that says it's illegal, but allowing software to clear SMXE in that > case seems all kinds of odd. I am pretty sure I coded this up using the pseudo code in the TXT dev guide and some guidance from Intel/former Intel folks. I will revisit it to make sure it is correct. Thanks Ross > >> + >> + /* Do the SEXIT SMX operation */ >> + smx_getsec_sexit(); >> + >> + pr_info("TXT SEXIT complete.\n"); >> +}
diff --git a/arch/x86/kernel/slaunch.c b/arch/x86/kernel/slaunch.c index cd5aa34e395c..32b0c24a6484 100644 --- a/arch/x86/kernel/slaunch.c +++ b/arch/x86/kernel/slaunch.c @@ -523,3 +523,76 @@ void __init slaunch_setup_txt(void) pr_info("Intel TXT setup complete\n"); } + +static inline void smx_getsec_sexit(void) +{ + asm volatile (".byte 0x0f,0x37\n" + : : "a" (SMX_X86_GETSEC_SEXIT)); +} + +/* + * Used during kexec and on reboot paths to finalize the TXT state + * and do an SEXIT exiting the DRTM and disabling SMX mode. + */ +void slaunch_finalize(int do_sexit) +{ + u64 one = TXT_REGVALUE_ONE, val; + void __iomem *config; + + if ((slaunch_get_flags() & (SL_FLAG_ACTIVE | SL_FLAG_ARCH_TXT)) != + (SL_FLAG_ACTIVE | SL_FLAG_ARCH_TXT)) + return; + + config = ioremap(TXT_PRIV_CONFIG_REGS_BASE, TXT_NR_CONFIG_PAGES * + PAGE_SIZE); + if (!config) { + pr_emerg("Error SEXIT failed to ioremap TXT private reqs\n"); + return; + } + + /* Clear secrets bit for SEXIT */ + memcpy_toio(config + TXT_CR_CMD_NO_SECRETS, &one, sizeof(one)); + memcpy_fromio(&val, config + TXT_CR_E2STS, sizeof(val)); + + /* Unlock memory configurations */ + memcpy_toio(config + TXT_CR_CMD_UNLOCK_MEM_CONFIG, &one, sizeof(one)); + memcpy_fromio(&val, config + TXT_CR_E2STS, sizeof(val)); + + /* Close the TXT private register space */ + memcpy_toio(config + TXT_CR_CMD_CLOSE_PRIVATE, &one, sizeof(one)); + memcpy_fromio(&val, config + TXT_CR_E2STS, sizeof(val)); + + /* + * Calls to iounmap are not being done because of the state of the + * system this late in the kexec process. Local IRQs are disabled and + * iounmap causes a TLB flush which in turn causes a warning. Leaving + * thse mappings is not an issue since the next kernel is going to + * completely re-setup memory management. + */ + + /* Map public registers and do a final read fence */ + config = ioremap(TXT_PUB_CONFIG_REGS_BASE, TXT_NR_CONFIG_PAGES * + PAGE_SIZE); + if (!config) { + pr_emerg("Error SEXIT failed to ioremap TXT public reqs\n"); + return; + } + + memcpy_fromio(&val, config + TXT_CR_E2STS, sizeof(val)); + + pr_emerg("TXT clear secrets bit and unlock memory complete.\n"); + + if (!do_sexit) + return; + + if (smp_processor_id() != 0) + panic("Error TXT SEXIT must be called on CPU 0\n"); + + /* Disable SMX mode */ + cr4_set_bits(X86_CR4_SMXE); + + /* Do the SEXIT SMX operation */ + smx_getsec_sexit(); + + pr_info("TXT SEXIT complete.\n"); +} diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c index be5642a4ec49..98b2db21a952 100644 --- a/kernel/kexec_core.c +++ b/kernel/kexec_core.c @@ -40,6 +40,7 @@ #include <linux/hugetlb.h> #include <linux/objtool.h> #include <linux/kmsg_dump.h> +#include <linux/slaunch.h> #include <asm/page.h> #include <asm/sections.h> @@ -1264,6 +1265,9 @@ int kernel_kexec(void) cpu_hotplug_enable(); pr_notice("Starting new kernel\n"); machine_shutdown(); + + /* Finalize TXT registers and do SEXIT */ + slaunch_finalize(1); } kmsg_dump(KMSG_DUMP_SHUTDOWN);
Prior to running the next kernel via kexec, the Secure Launch code closes down private SMX resources and does an SEXIT. This allows the next kernel to start normally without any issues starting the APs etc. Signed-off-by: Ross Philipson <ross.philipson@oracle.com> --- arch/x86/kernel/slaunch.c | 73 +++++++++++++++++++++++++++++++++++++++ kernel/kexec_core.c | 4 +++ 2 files changed, 77 insertions(+)