From: ALOK TIWARI <alok.a.tiwari@oracle.com>
To: Ross Philipson <ross.philipson@oracle.com>,
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, iommu@lists.linux.dev
Cc: 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, corbet@lwn.net,
ebiederm@xmission.com, dwmw2@infradead.org,
baolu.lu@linux.intel.com, kanth.ghatraju@oracle.com,
andrew.cooper3@citrix.com, trenchboot-devel@googlegroups.com
Subject: Re: [PATCH v14 12/19] kexec: Secure Launch kexec SEXIT support
Date: Thu, 24 Apr 2025 01:28:38 +0530 [thread overview]
Message-ID: <ad920d74-0a69-4070-a396-f17171b8678c@oracle.com> (raw)
In-Reply-To: <20250421162712.77452-13-ross.philipson@oracle.com>
On 21-04-2025 21:57, 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>
> ---
[clip]
> +static inline void smx_getsec_sexit(void)
> +{
> + asm volatile ("getsec\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.
'do an SEXIT exiting', sounds awkward. Changed to 'perform an SEXIT to
exit' for clarity.
> + */
> +void slaunch_finalize(int do_sexit)
> +{
> + u64 one = TXT_REGVALUE_ONE, val;
> + void __iomem *config;
> +
> + if (!slaunch_is_txt_launch())
> + 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
typo thse -> these
"are not being done because of the state of the system" can be
simplified to "are skipped due to the system state."
"Calls to iounmap are skipped due to the system state this late in the
kexec process"
> + * 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");
reqs or regs ?
Assuming you meant registers (regs), not requests (reqs)
> + 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");
Prefixing with "TXT:"
'Error' is redundant — panic() itself implies a fatal error.
we can use panic("TXT: SEXIT must be called on CPU 0\n");
> +
> + /* In case SMX mode was disabled, enable it for SEXIT */
> + cr4_set_bits(X86_CR4_SMXE);
> +
> + /* Do the SEXIT SMX operation */
> + smx_getsec_sexit();
> +
Thanks,
Alok
next prev parent reply other threads:[~2025-04-23 19:59 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-21 16:26 [PATCH v14 00/19] x86: Trenchboot secure dynamic launch Linux kernel support Ross Philipson
2025-04-21 16:26 ` [PATCH v14 01/19] Documentation/x86: Secure Launch kernel documentation Ross Philipson
2025-06-18 8:33 ` Mowka, Mateusz
2025-06-18 15:02 ` Dave Hansen
2025-04-21 16:26 ` [PATCH v14 02/19] x86: Secure Launch Kconfig Ross Philipson
2025-04-21 17:41 ` Randy Dunlap
2025-04-22 19:32 ` ross.philipson
2025-06-18 8:32 ` Mowka, Mateusz
2025-04-21 16:26 ` [PATCH v14 03/19] x86: Secure Launch Resource Table header file Ross Philipson
2025-04-21 19:18 ` ALOK TIWARI
2025-04-22 19:33 ` ross.philipson
2025-04-23 18:23 ` ALOK TIWARI
2025-04-23 20:04 ` ross.philipson
2025-04-24 12:36 ` Huang, Kai
2025-04-24 19:19 ` ross.philipson
2025-04-21 16:26 ` [PATCH v14 04/19] x86: Secure Launch main " Ross Philipson
2025-04-24 12:29 ` Huang, Kai
2025-04-24 18:56 ` ross.philipson
2025-06-23 11:44 ` Camacho Romero, Michal
2025-06-23 21:29 ` ross.philipson
2025-06-27 9:15 ` Camacho Romero, Michal
2025-04-21 16:26 ` [PATCH v14 05/19] x86: Add early SHA-1 support for Secure Launch early measurements Ross Philipson
2025-04-21 16:26 ` [PATCH v14 06/19] x86: Add early SHA-256 " Ross Philipson
2025-04-21 16:27 ` [PATCH v14 07/19] x86/msr: Add variable MTRR base/mask and x2apic ID registers Ross Philipson
2025-04-21 16:27 ` [PATCH v14 08/19] x86/boot: Place TXT MLE header in the kernel_info section Ross Philipson
2025-04-23 20:54 ` ALOK TIWARI
2025-04-21 16:27 ` [PATCH v14 09/19] x86: Secure Launch kernel early boot stub Ross Philipson
2025-04-22 1:18 ` Dave Hansen
2025-04-22 19:38 ` ross.philipson
2025-04-23 20:38 ` ALOK TIWARI
2025-04-23 21:07 ` ross.philipson
2025-04-21 16:27 ` [PATCH v14 10/19] x86: Secure Launch kernel late " Ross Philipson
2025-04-21 16:27 ` [PATCH v14 11/19] x86: Secure Launch SMP bringup support Ross Philipson
2025-04-21 16:27 ` [PATCH v14 12/19] kexec: Secure Launch kexec SEXIT support Ross Philipson
2025-04-23 19:58 ` ALOK TIWARI [this message]
2025-04-23 20:07 ` ross.philipson
2025-04-21 16:27 ` [PATCH v14 13/19] x86/reboot: Secure Launch SEXIT support on reboot paths Ross Philipson
2025-04-21 22:57 ` Dave Hansen
2025-04-22 19:31 ` ross.philipson
2025-04-21 16:27 ` [PATCH v14 14/19] tpm, tpm_tis: Close all localities Ross Philipson
2025-04-21 16:27 ` [PATCH v14 15/19] tpm, tpm_tis: Address positive localities in tpm_tis_request_locality() Ross Philipson
2025-04-21 16:27 ` [PATCH v14 16/19] tpm, tpm_tis: Allow locality to be set to a different value Ross Philipson
2025-04-22 10:20 ` Stefano Garzarella
2025-04-23 19:38 ` Daniel P. Smith
2025-04-21 16:27 ` [PATCH v14 17/19] tpm, sysfs: Show locality used by kernel Ross Philipson
2025-04-21 16:27 ` [PATCH v14 18/19] x86: Secure Launch late initcall platform module Ross Philipson
2025-04-28 17:38 ` Andy Lutomirski
2025-04-30 1:40 ` Daniel P. Smith
2025-04-30 18:51 ` Andy Lutomirski
2025-04-21 16:27 ` [PATCH v14 19/19] x86/efi: EFI stub DRTM launch support for Secure Launch Ross Philipson
2025-04-21 20:52 ` [PATCH v14 00/19] x86: Trenchboot secure dynamic launch Linux kernel support Dave Hansen
2025-04-21 21:00 ` Andrew Cooper
2025-04-22 18:17 ` Andrew Cooper
2025-04-22 19:16 ` Dave Hansen
2025-04-22 21:26 ` Ard Biesheuvel
2025-04-22 23:21 ` Dave Hansen
2025-04-24 18:45 ` Dave Hansen
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=ad920d74-0a69-4070-a396-f17171b8678c@oracle.com \
--to=alok.a.tiwari@oracle.com \
--cc=James.Bottomley@hansenpartnership.com \
--cc=andrew.cooper3@citrix.com \
--cc=ardb@kernel.org \
--cc=baolu.lu@linux.intel.com \
--cc=bp@alien8.de \
--cc=corbet@lwn.net \
--cc=dave.hansen@linux.intel.com \
--cc=davem@davemloft.net \
--cc=dpsmith@apertussolutions.com \
--cc=dwmw2@infradead.org \
--cc=ebiederm@xmission.com \
--cc=herbert@gondor.apana.org.au \
--cc=hpa@zytor.com \
--cc=iommu@lists.linux.dev \
--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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).