From: Simon Horman <horms@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, iommu@lists.linux-foundation.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, ardb@kernel.org,
mjg59@srcf.ucam.org, James.Bottomley@hansenpartnership.com,
luto@amacapital.net, nivedita@alum.mit.edu,
kanth.ghatraju@oracle.com, trenchboot-devel@googlegroups.com
Subject: Re: [PATCH v6 07/14] x86: Secure Launch kernel early boot stub
Date: Fri, 5 May 2023 19:47:24 +0200 [thread overview]
Message-ID: <ZFVBLCLVK7AAStst@kernel.org> (raw)
In-Reply-To: <20230504145023.835096-8-ross.philipson@oracle.com>
On Thu, May 04, 2023 at 02:50:16PM +0000, Ross Philipson wrote:
> The Secure Launch (SL) stub provides the entry point for Intel TXT (and
> later AMD SKINIT) to vector to during the late launch. The symbol
> sl_stub_entry is that entry point and its offset into the kernel is
> conveyed to the launching code using the MLE (Measured Launch
> Environment) header in the structure named mle_header. The offset of the
> MLE header is set in the kernel_info. The routine sl_stub contains the
> very early late launch setup code responsible for setting up the basic
> environment to allow the normal kernel startup_32 code to proceed. It is
> also responsible for properly waking and handling the APs on Intel
> platforms. The routine sl_main which runs after entering 64b mode is
> responsible for measuring configuration and module information before
> it is used like the boot params, the kernel command line, the TXT heap,
> an external initramfs, etc.
>
> Signed-off-by: Ross Philipson <ross.philipson@oracle.com>
...
> diff --git a/arch/x86/boot/compressed/sl_main.c b/arch/x86/boot/compressed/sl_main.c
...
> +static void *evtlog_base;
> +static u32 evtlog_size;
> +static struct txt_heap_event_log_pointer2_1_element *log20_elem;
> +static u32 tpm_log_ver = SL_TPM12_LOG;
> +struct tcg_efi_specid_event_algs tpm_algs[SL_TPM20_MAX_ALGS] = {0};
tpm_algs seems to only be used in this file.
Should it be static?
> +
> +extern u32 sl_cpu_type;
> +extern u32 sl_mle_start;
> +extern struct boot_params *boot_params;
> +
> +static u64 sl_txt_read(u32 reg)
Perhaps reg should have an __iomem annotation.
> +{
> + return readq((void *)(u64)(TXT_PRIV_CONFIG_REGS_BASE + reg));
> +}
> +
> +static void sl_txt_write(u32 reg, u64 val)
Likewise here.
...
> +static void sl_check_pmr_coverage(void *base, u32 size, bool allow_hi)
> +{
> + struct txt_os_sinit_data *os_sinit_data;
> + void *end = base + size;
> + void *txt_heap;
> +
> + if (!(sl_cpu_type & SL_CPU_INTEL))
> + return;
> +
> + txt_heap = (void *)sl_txt_read(TXT_CR_HEAP_BASE);
> + os_sinit_data = txt_os_sinit_data_start(txt_heap);
> +
> + if ((end >= (void *)0x100000000ULL) &&
> + (base < (void *)0x100000000ULL))
> + sl_txt_reset(SL_ERROR_REGION_STRADDLE_4GB);
> +
> + /*
> + * Note that the late stub code validates that the hi PMR covers
> + * all memory above 4G. At this point the code can only check that
> + * regions are within the hi PMR but that is sufficient.
> + */
> + if ((end > (void *)0x100000000ULL) &&
> + (base >= (void *)0x100000000ULL)) {
> + if (allow_hi) {
> + if (end >= (void *)(os_sinit_data->vtd_pmr_hi_base +
> + os_sinit_data->vtd_pmr_hi_size))
> + sl_txt_reset(SL_ERROR_BUFFER_BEYOND_PMR);
> + } else
> + sl_txt_reset(SL_ERROR_REGION_ABOVE_4GB);
nit: if any arm of a condition has '{}' then all arms should have them.
So:
} else {
sl_txt_reset(SL_ERROR_REGION_ABOVE_4GB);
}
Also elsewhere in this patch.
> + }
> +
> + if (end >= (void *)os_sinit_data->vtd_pmr_lo_size)
> + sl_txt_reset(SL_ERROR_BUFFER_BEYOND_PMR);
> +}
> +
> +/*
> + * Some MSRs are modified by the pre-launch code including the MTRRs.
> + * The early MLE code has to restore these values. This code validates
> + * the values after they are measured.
> + */
> +static void sl_txt_validate_msrs(struct txt_os_mle_data *os_mle_data)
> +{
> + struct slr_txt_mtrr_state *saved_bsp_mtrrs;
> + u64 mtrr_caps, mtrr_def_type, mtrr_var;
> + struct slr_entry_intel_info *txt_info;
> + u64 misc_en_msr;
> + u32 vcnt, i;
> +
> + txt_info = (struct slr_entry_intel_info *)os_mle_data->txt_info;
> + saved_bsp_mtrrs = &(txt_info->saved_bsp_mtrrs);
nit: unnecessary parentheses
...
> +static void sl_validate_event_log_buffer(void)
> +{
> + struct txt_os_sinit_data *os_sinit_data;
> + void *txt_heap, *txt_end;
> + void *mle_base, *mle_end;
> + void *evtlog_end;
> +
> + if ((u64)evtlog_size > (LLONG_MAX - (u64)evtlog_base))
> + sl_txt_reset(SL_ERROR_INTEGER_OVERFLOW);
> + evtlog_end = evtlog_base + evtlog_size;
> +
> + txt_heap = (void *)sl_txt_read(TXT_CR_HEAP_BASE);
> + txt_end = txt_heap + sl_txt_read(TXT_CR_HEAP_SIZE);
> + os_sinit_data = txt_os_sinit_data_start(txt_heap);
> +
> + mle_base = (void *)(u64)sl_mle_start;
> + mle_end = mle_base + os_sinit_data->mle_size;
> +
> + /*
> + * This check is to ensure the event log buffer does not overlap with
> + * the MLE image.
> + */
> + if ((evtlog_base >= mle_end) &&
> + (evtlog_end > mle_end))
> + goto pmr_check; /* above */
Ditto.
Also, the if condition could be one line.
Also in several other places in this patch.
> +
> + if ((evtlog_end <= mle_base) &&
> + (evtlog_base < mle_base))
> + goto pmr_check; /* below */
> +
> + sl_txt_reset(SL_ERROR_MLE_BUFFER_OVERLAP);
> +
> +pmr_check:
> + /*
> + * The TXT heap is protected by the DPR. If the TPM event log is
> + * inside the TXT heap, there is no need for a PMR check.
> + */
> + if ((evtlog_base > txt_heap) &&
> + (evtlog_end < txt_end))
> + return;
> +
> + sl_check_pmr_coverage(evtlog_base, evtlog_size, true);
> +}
> +static void sl_process_extend_policy(struct slr_table *slrt)
> +{
> + struct slr_entry_policy *policy;
> + struct slr_policy_entry *entry;
> + u16 i = 0;
> +
> + policy =(struct slr_entry_policy *)
nit: space after '='
...
> +static void sl_process_extend_uefi_config(struct slr_table *slrt)
> +{
> + struct slr_entry_uefi_config *uefi_config;
> + struct slr_uefi_cfg_entry *uefi_entry;
> + u64 i;
> +
> + uefi_config =(struct slr_entry_uefi_config *)
> + slr_next_entry_by_tag(slrt, NULL, SLR_ENTRY_UEFI_CONFIG);
> +
> + /* Optionally here depending on how SL kernel was booted */
> + if (!uefi_config)
> + return;
> +
> + uefi_entry = (struct slr_uefi_cfg_entry *)((u8 *)uefi_config + sizeof(*uefi_config));
> +
> + for ( ; i < uefi_config->nr_entries; i++, uefi_entry++) {
nit: i seems to be used without first being initialised.
> + sl_tpm_extend_evtlog(uefi_entry->pcr, TXT_EVTYPE_SLAUNCH,
> + (void *)uefi_entry->cfg, uefi_entry->size,
> + uefi_entry->evt_info);
> + }
> +}
> +
> +asmlinkage __visible void sl_check_region(void *base, u32 size)
> +{
> + sl_check_pmr_coverage(base, size, false);
> +}
I'm a nit unsure, what to do here, but clang-16 with W=1 says the following.
arch/x86/boot/compressed/sl_main.c:533:27: warning: no previous prototype for function 'sl_main' [-Wmissing-prototypes]
asmlinkage __visible void sl_main(void *bootparams)
^
arch/x86/boot/compressed/sl_main.c:533:22: note: declare 'static' if the function is not intended to be used outside of this translation unit
asmlinkage __visible void sl_main(void *bootparams)
^
static
...
> diff --git a/arch/x86/boot/compressed/sl_stub.S b/arch/x86/boot/compressed/sl_stub.S
> new file mode 100644
> index 0000000..2d8aa3a
> --- /dev/null
> +++ b/arch/x86/boot/compressed/sl_stub.S
> @@ -0,0 +1,690 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +
> +/*
> + * Secure Launch protected mode entry point.
> + *
> + * Copyright (c) 2022, Oracle and/or its affiliates.
> + */
> + .code32
> + .text
> +#include <linux/linkage.h>
> +#include <asm/segment.h>
> +#include <asm/msr.h>
> +#include <asm/processor-flags.h>
> +#include <asm/asm-offsets.h>
> +#include <asm/bootparam.h>
> +#include <asm/page_types.h>
> +#include <asm/irq_vectors.h>
> +#include <linux/slr_table.h>
> +#include <linux/slaunch.h>
> +
> +/* CPUID: leaf 1, ECX, SMX feature bit */
> +#define X86_FEATURE_BIT_SMX (1 << 6)
> +
> +/* Can't include apiddef.h in asm */
> +#define XAPIC_ENABLE (1 << 11)
> +#define X2APIC_ENABLE (1 << 10)
> +
> +/* Can't include traps.h in asm */
> +#define X86_TRAP_NMI 2
> +
> +/* Can't include mtrr.h in asm */
> +#define MTRRphysBase0 0x200
> +
> +#define IDT_VECTOR_LO_BITS 0
> +#define IDT_VECTOR_HI_BITS 6
> +
> +/*
> + * See the comment in head_64.S for detailed informatoin on what this macro
nit: s/informatoin/information/
...
> diff --git a/arch/x86/include/uapi/asm/bootparam.h b/arch/x86/include/uapi/asm/bootparam.h
> index 01d19fc..74e3e7df 100644
> --- a/arch/x86/include/uapi/asm/bootparam.h
> +++ b/arch/x86/include/uapi/asm/bootparam.h
> @@ -26,6 +26,7 @@
> /* loadflags */
> #define LOADED_HIGH (1<<0)
> #define KASLR_FLAG (1<<1)
> +#define SLAUNCH_FLAG (1<<2)
> #define QUIET_FLAG (1<<5)
> #define KEEP_SEGMENTS (1<<6)
> #define CAN_USE_HEAP (1<<7)
nit: please consider using BIT()
...
next prev parent reply other threads:[~2023-05-05 17:49 UTC|newest]
Thread overview: 100+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-04 14:50 [PATCH v6 00/14] x86: Trenchboot secure dynamic launch Linux kernel support Ross Philipson
2023-05-04 14:50 ` [PATCH v6 01/14] x86/boot: Place kernel_info at a fixed offset Ross Philipson
2023-05-04 14:50 ` [PATCH v6 02/14] Documentation/x86: Secure Launch kernel documentation Ross Philipson
2023-05-05 16:19 ` Simon Horman
2023-05-05 17:32 ` Ross Philipson
2023-05-06 8:48 ` Bagas Sanjaya
2023-05-10 15:41 ` Ross Philipson
2023-05-12 10:47 ` Matthew Garrett
2023-06-16 16:44 ` Daniel P. Smith
2023-06-16 16:54 ` Matthew Garrett
2023-06-16 18:21 ` Daniel P. Smith
2023-05-12 13:19 ` Thomas Gleixner
2023-05-04 14:50 ` [PATCH v6 03/14] x86: Secure Launch Kconfig Ross Philipson
2023-05-04 14:50 ` [PATCH v6 04/14] x86: Secure Launch Resource Table header file Ross Philipson
2023-05-05 16:22 ` Simon Horman
2023-05-05 17:34 ` Ross Philipson
2023-05-10 23:04 ` Jarkko Sakkinen
2023-05-15 20:58 ` Daniel P. Smith
2023-05-12 10:55 ` Matthew Garrett
2023-05-15 21:15 ` Daniel P. Smith
2023-05-15 21:22 ` Matthew Garrett
2023-05-16 0:41 ` Daniel P. Smith
2023-05-16 1:43 ` Matthew Garrett
2023-06-16 20:01 ` Daniel P. Smith
2023-06-16 20:15 ` Matthew Garrett
2023-07-07 19:31 ` Daniel P. Smith
2023-05-04 14:50 ` [PATCH v6 05/14] x86: Secure Launch main " Ross Philipson
2023-05-05 16:25 ` Simon Horman
2023-05-05 17:37 ` Ross Philipson
2023-05-12 11:00 ` Matthew Garrett
2023-05-12 16:10 ` Ross Philipson
2023-10-31 21:37 ` ross.philipson
2023-05-04 14:50 ` [PATCH v6 06/14] x86: Add early SHA support for Secure Launch early measurements Ross Philipson
2023-05-05 16:34 ` Simon Horman
2023-05-09 16:09 ` Daniel P. Smith
2023-05-10 1:21 ` Eric Biggers
2023-05-10 22:28 ` Jarkko Sakkinen
2023-05-12 11:04 ` Matthew Garrett
2023-05-12 11:18 ` Ard Biesheuvel
2023-05-12 11:28 ` Matthew Garrett
2023-05-12 11:58 ` Ard Biesheuvel
2023-05-12 12:24 ` Andrew Cooper
2023-05-14 18:18 ` Eric Biggers
2023-05-14 19:11 ` Matthew Garrett
2023-05-12 13:24 ` Thomas Gleixner
2023-05-12 16:13 ` Matthew Garrett
2023-05-12 18:17 ` Thomas Gleixner
2023-05-12 19:12 ` Matthew Garrett
2023-05-12 19:42 ` Andrew Cooper
2023-05-15 21:23 ` Daniel P. Smith
2023-05-11 3:33 ` Herbert Xu
2023-05-16 0:50 ` Daniel P. Smith
2023-05-04 14:50 ` [PATCH v6 07/14] x86: Secure Launch kernel early boot stub Ross Philipson
2023-05-05 17:47 ` Simon Horman [this message]
2023-05-05 18:58 ` Ross Philipson
2023-05-05 19:46 ` Simon Horman
2023-05-12 11:26 ` Matthew Garrett
2023-05-12 16:17 ` Ross Philipson
2023-05-12 16:27 ` Matthew Garrett
2023-05-16 1:11 ` Daniel P. Smith
2023-05-16 1:45 ` Matthew Garrett
2023-06-15 18:00 ` Ross Philipson
2023-05-12 18:04 ` Thomas Gleixner
2023-05-15 20:13 ` Ross Philipson
2023-09-20 21:40 ` ross.philipson
2023-05-04 14:50 ` [PATCH v6 08/14] x86: Secure Launch kernel late " Ross Philipson
2023-05-05 17:52 ` Simon Horman
2023-05-05 18:59 ` Ross Philipson
2023-05-10 23:02 ` Jarkko Sakkinen
2023-05-12 15:58 ` Ross Philipson
2023-05-24 2:55 ` Jarkko Sakkinen
2023-05-12 15:44 ` Thomas Gleixner
2023-05-15 20:06 ` Ross Philipson
2023-05-04 14:50 ` [PATCH v6 09/14] x86: Secure Launch SMP bringup support Ross Philipson
2023-05-05 17:54 ` Simon Horman
2023-05-05 18:59 ` Ross Philipson
2023-05-10 22:55 ` Jarkko Sakkinen
2023-05-11 16:21 ` Ross Philipson
2023-05-12 18:02 ` Thomas Gleixner
2023-05-15 20:19 ` Ross Philipson
2023-05-04 14:50 ` [PATCH v6 10/14] kexec: Secure Launch kexec SEXIT support Ross Philipson
2023-05-04 14:50 ` [PATCH v6 11/14] reboot: Secure Launch SEXIT support on reboot paths Ross Philipson
2023-05-12 11:40 ` Matthew Garrett
2023-05-15 18:16 ` Ross Philipson
2023-05-16 1:23 ` Daniel P. Smith
2023-05-04 14:50 ` [PATCH v6 12/14] x86: Secure Launch late initcall platform module Ross Philipson
2023-05-05 19:42 ` Simon Horman
2023-05-08 15:07 ` Ross Philipson
2023-05-10 22:39 ` Jarkko Sakkinen
2023-05-12 15:53 ` Ross Philipson
2023-05-10 22:40 ` Jarkko Sakkinen
2023-05-12 15:54 ` Ross Philipson
2023-05-04 14:50 ` [PATCH v6 13/14] tpm: Allow locality 2 to be set when initializing the TPM for Secure Launch Ross Philipson
2023-05-12 11:43 ` Matthew Garrett
2023-05-12 16:22 ` Ross Philipson
2023-05-16 1:37 ` Daniel P. Smith
2023-05-04 14:50 ` [PATCH v6 14/14] x86: EFI stub DRTM launch support " Ross Philipson
2023-05-05 8:39 ` [PATCH v6 00/14] x86: Trenchboot secure dynamic launch Linux kernel support Bagas Sanjaya
2023-05-05 15:45 ` Ross Philipson
2023-05-06 7:56 ` Bagas Sanjaya
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=ZFVBLCLVK7AAStst@kernel.org \
--to=horms@kernel.org \
--cc=James.Bottomley@hansenpartnership.com \
--cc=ardb@kernel.org \
--cc=bp@alien8.de \
--cc=dpsmith@apertussolutions.com \
--cc=hpa@zytor.com \
--cc=iommu@lists.linux-foundation.org \
--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=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).