From: Alexander Graf
With KHO in place, let's add documentation that describes what it is and
how to use it.
Signed-off-by: Alexander Graf
Co-developed-by: Mike Rapoport (Microsoft)
Signed-off-by: Mike Rapoport (Microsoft)
Co-developed-by: Changyuan Lyu
Signed-off-by: Changyuan Lyu
---
...
From: "Mike Rapoport (Microsoft)"
We introduced KHO into Linux: A framework that allows Linux to pass
metadata and memory across kexec from Linux to Linux. KHO reuses fdt
as file format and shares a lot of the same properties of firmware-to-
Linux boot formats: It needs a stable, documented ABI t
From: Alexander Graf
Linux has recently gained support for "reserve_mem": A mechanism to
allocate a region of memory early enough in boot that we can cross our
fingers and hope it stays at the same location during most boots, so we
can store for example ftrace buffers into it.
Thanks to KASLR, w
From: "Mike Rapoport (Microsoft)"
memblock_reserve() does not distinguish memory used by firmware from memory
used by kernel.
The distinction is nice to have for accounting of early memory allocations
and reservations, but it is essential for kexec handover (kho) to know how
much memory kernel c
From: Alexander Graf
We now have all bits in place to support KHO kexecs. This patch adds
awareness of KHO in the kexec file as well as boot path for x86 and
adds the respective kconfig option to the architecture so that it can
use KHO successfully.
In addition, it enlightens it decompression co
On 11-04-2025 02:11, Ross Philipson wrote:
+
+ - Entry from the dynamic launch jumps to the SL stub.
+ - SL stub fixes up the world on the BSP.
+ - For TXT, SL stub wakes the APs, fixes up their worlds.
+ - For TXT, APs are left halted using MONITOR/MWAIT intructions.
typo intructions -> ins
From: Alexander Graf
We now have all bits in place to support KHO kexecs. Add awareness of
KHO in the kexec file as well as boot path for arm64 and adds the
respective kconfig option to the architecture so that it can use KHO
successfully.
Changes to the "chosen" node have been sent to
https://g
From: Alexander Graf
We have all generic code in place now to support Kexec with KHO. This
patch adds a config option that depends on architecture support to
enable KHO support.
Signed-off-by: Alexander Graf
Co-developed-by: Mike Rapoport (Microsoft)
Signed-off-by: Mike Rapoport (Microsoft)
S
From: Alexander Graf
Kexec has 2 modes: A user space driven mode and a kernel driven mode.
For the kernel driven mode, kernel code determines the physical
addresses of all target buffers that the payload gets copied into.
With KHO, we can only safely copy payloads into the "scratch area".
Teach
From: "Mike Rapoport (Microsoft)"
Introduce APIs allowing KHO users to preserve memory across kexec and
get access to that memory after boot of the kexeced kernel
kho_preserve_folio() - record a folio to be preserved over kexec
kho_restore_folio() - recreates the folio from the preserved memory
From: Alexander Graf
When we have a KHO kexec, we get an FDT blob and scratch region to
populate the state of the system. Provide helper functions that allow
architecture code to easily handle memory reservations based on them and
give device drivers visibility into the KHO FDT and memory reserva
From: Alexander Graf
Add the infrastructure to generate Kexec HandOver metadata. Kexec
HandOver is a mechanism that allows Linux to preserve state - arbitrary
properties as well as memory locations - across kexec.
It does so using 2 concepts:
1) KHO FDT - Every KHO kexec carries a KHO specifi
From: "Mike Rapoport (Microsoft)"
With deferred initialization of struct page it will be necessary to
initialize memory map for KHO scratch regions early.
Add memmap_init_kho_scratch() method that will allow such initialization
in upcoming patches.
Signed-off-by: Mike Rapoport (Microsoft)
Sign
From: Alexander Graf
With KHO (Kexec HandOver), we need a way to ensure that the new kernel
does not allocate memory on top of any memory regions that the previous
kernel was handing over. But to know where those are, we need to include
them in the memblock.reserved array which may not be big eno
From: "Mike Rapoport (Microsoft)"
to denote areas that were reserved for kernel use either directly with
memblock_reserve_kern() or via memblock allocations.
Signed-off-by: Mike Rapoport (Microsoft)
Co-developed-by: Changyuan Lyu
Signed-off-by: Changyuan Lyu
---
include/linux/memblock.h
Hi,
This is the version 6 of Alexander Graf and Mike Rapoport's
"kexec: introduce Kexec HandOver (KHO)" series
(https://lore.kernel.org/all/20250320015551.2157511-1-changyu...@google.com/).
The patches are also available in git:
https://github.com/googleprodkernel/linux-liveupdate/tree/kho/v6.
v
On Wed, Mar 19, 2025 at 18:55:47 -0700, Changyuan Lyu
wrote:
> From: Alexander Graf
> [...]
> +/**
> + * early_init_dt_check_kho - Decode info required for kexec handover from DT
> + */
> +static void __init early_init_dt_check_kho(void)
> +{
> + unsigned long node = chosen_node_offset;
> +
From: "Daniel P. Smith"
Secure Launch is written to be compliant with the Intel TXT Measured Launch
Developer's Guide. The MLE Guide dictates that the system can be configured to
use both the SHA-1 and SHA-2 hashing algorithms.
Regardless of the preference towards SHA-2, if the firmware elected
The Secure Launch (SL) stub provides the entry point for Intel TXT to
jump to during the dynamic launch. The symbol sl_stub_entry is that entry
point and its offset into the kernel is conveyed to the launching code using
the Measured Launch Environment (MLE) header in the structure named mle_header
From: "Daniel P. Smith"
Validate that the input locality is within the correct range, as specified
by TCG standards, and increase the locality count also for the positive
localities.
Signed-off-by: Daniel P. Smith
Signed-off-by: Ross Philipson
Signed-off-by: Jarkko Sakkinen
---
drivers/char/
From: "Daniel P. Smith"
The Secure Launch platform module is a late init module. During the
init call, the TPM event log is read and measurements taken in the
early boot stub code are located. These measurements are extended
into the TPM PCRs using the mainline TPM kernel driver.
The platform mo
If the MLE kernel is being powered off, rebooted or halted,
then SEXIT must be called. Note that the SEXIT GETSEC leaf
can only be called after a machine_shutdown() has been done on
these paths. The machine_shutdown() is not called on a few paths
like when poweroff action does not have a poweroff c
DRTM needs to be able to set the locality used by kernel. Provide
a one-shot function tpm_chip_set_locality() for the purpose.
Signed-off-by: Ross Philipson
Signed-off-by: Jarkko Sakkinen
---
drivers/char/tpm/tpm-chip.c | 33 -
drivers/char/tpm/tpm_tis_core.c
Expose the locality used by the kernel to sysfs.
Signed-off-by: Ross Philipson
Signed-off-by: Jarkko Sakkinen
---
drivers/char/tpm/tpm-sysfs.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/char/tpm/tpm-sysfs.c b/drivers/char/tpm/tpm-sysfs.c
index 94231f052ea7..2da5857e
From: "Daniel P. Smith"
There are environments, for example, those that comply with the TCG D-RTM
specification that requires the TPM to be left in locality 2. Prepare
kernel for such environments by closing all the localities.
Signed-off-by: Daniel P. Smith
Signed-off-by: Ross Philipson
Signe
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
Rev
On Intel, the APs are left in a well documented state after TXT performs
the late launch. Specifically they cannot have #INIT asserted on them so
a standard startup via INIT/SIPI/SIPI cannot be performed. Instead the
early SL stub code uses MONITOR and MWAIT to park the APs. The realmode/init.c
cod
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
---
arch/x86/kernel/slaunch.c | 72
This is a reposting of the recently posted Secure Launch v13 patch set.
This version contains a summary of what is already reviewed in the patch
set and what patches need reviews:
- Patches 1/8/14/15/16/17/19 already have reviews done for them.
- Patches 2/3/4/7/9/10/11/12/13/18 need to be revie
From: "Daniel P. Smith"
Introduce background, overview and configuration/ABI information
for the Secure Launch kernel feature.
Signed-off-by: Daniel P. Smith
Signed-off-by: Ross Philipson
Reviewed-by: Bagas Sanjaya
---
Documentation/security/index.rst | 1 +
.../security/launc
The routine slaunch_setup() is called out of the x86 specific setup_arch()
routine during early kernel boot. After determining what platform is
present, various operations specific to that platform occur. This
includes finalizing setting for the platform late launch and verifying
that memory protec
The Measured Launch Environment (MLE) header must be locatable by the
boot loader and Intel TXT must be setup to do a launch with this header's
location. While the offset to the kernel_info structure does not need
to be at a fixed offset, the offsets in the header must be relative
offsets from the
Add the MSR values required by Secure Launch to locate particular CPU cores
during application processor (AP) startup, and restore the MTRR state after
an Intel TXT launch.
Signed-off-by: Ross Philipson
---
arch/x86/include/asm/msr-index.h | 5 +
1 file changed, 5 insertions(+)
diff --git a
From: "Daniel P. Smith"
The SHA-256 algorithm is necessary to measure configuration information into
the TPM as early as possible before using the values. This implementation
uses the established approach of #including the SHA-256 libraries directly in
the code since the compressed kernel is not
Introduce the main Secure Launch header file used in the early SL stub
and the early setup code.
This header file contains the following categories:
- Secure Launch implementation specific structures and definitions.
- Intel TXT architecture specific DRTM structures, definitions and functions
us
The Secure Launch Specification is an architectural agnostic, software neutral
API/ABI maintainted by the TrenchBoot project. It's function is to allow any
compliant boot loader to communicate the pre-launch configuration to any
compliant post-launch kernel. This API/ABI is referred to as the Secur
Initial bits to bring in Secure Launch functionality. Add Kconfig
options for compiling in/out the Secure Launch code.
Signed-off-by: Ross Philipson
---
arch/x86/Kconfig | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 9427b5292ca2..a9278
On Thu, 2025-04-10 at 11:49 -0700, steven chen wrote:
> On 4/10/2025 11:04 AM, Mimi Zohar wrote:
> > On Thu, 2025-04-10 at 09:59 -0700, steven chen wrote:
> > > On 4/10/2025 2:54 AM, Baoquan He wrote:
> > > > On 04/02/25 at 05:47am, steven chen wrote:
> > > > > The extra memory allocated for carryi
On 4/10/2025 11:04 AM, Mimi Zohar wrote:
On Thu, 2025-04-10 at 09:59 -0700, steven chen wrote:
On 4/10/2025 2:54 AM, Baoquan He wrote:
On 04/02/25 at 05:47am, steven chen wrote:
The extra memory allocated for carrying the IMA measurement list across
kexec is hard-coded as half a PAGE. Make it
On Thu, 2025-04-10 at 09:59 -0700, steven chen wrote:
> On 4/10/2025 2:54 AM, Baoquan He wrote:
> > On 04/02/25 at 05:47am, steven chen wrote:
> > > The extra memory allocated for carrying the IMA measurement list across
> > > kexec is hard-coded as half a PAGE. Make it configurable.
> > >
> > >
On 4/10/2025 2:54 AM, Baoquan He wrote:
On 04/02/25 at 05:47am, steven chen wrote:
The extra memory allocated for carrying the IMA measurement list across
kexec is hard-coded as half a PAGE. Make it configurable.
Define a Kconfig option, IMA_KEXEC_EXTRA_MEMORY_KB, to configure the
extra memory
On 4/7/2025 8:17 PM, Baoquan He wrote:
On 04/02/25 at 05:47am, steven chen wrote:
The kexec_calculate_store_digests() function calculates and stores the
digest of the segment during the kexec_file_load syscall, where the
IMA segment is also allocated.
With this series, the IMA segment will be u
On 4/8/2025 9:17 AM, Mimi Zohar wrote:
On Wed, 2025-04-02 at 05:47 -0700, steven chen wrote:
ima_dump_measurement_list() is called during kexec 'load', which may
result in loss of IMA measurements during kexec soft reboot. Due to
missed measurements that only occurred after kexec 'load', this fu
On 4/8/2025 7:21 AM, Mimi Zohar wrote:
On Wed, 2025-04-02 at 05:47 -0700, steven chen wrote:
The IMA log is currently copied to the new kernel during kexec 'load'
using ima_dump_measurement_list(). However, the log copied at kexec
'load' may result in loss of IMA measurements that only occurred
On 4/7/2025 8:10 PM, Baoquan He wrote:
On 04/02/25 at 05:47am, steven chen wrote:
Currently, the kernel behavior during kexec load is to fetch the IMA
measurements logs and store logs in kernel memory. When a kexec reboot is
triggered, these stored logs in the kernel memory are carried over to t
On 04/02/25 at 05:47am, steven chen wrote:
> The extra memory allocated for carrying the IMA measurement list across
> kexec is hard-coded as half a PAGE. Make it configurable.
>
> Define a Kconfig option, IMA_KEXEC_EXTRA_MEMORY_KB, to configure the
> extra memory (in kb) to be allocated for IMA
On 26 March 2025 15:16:00 CET, David Woodhouse wrote:
>Continuing the drip-feed of the exception handling support, on top of the
>current tip/x86/asm branch. This adds output to the serial port configured
>by earlyprintk, reduces the window during which exceptions can't be handled
>during the tran
47 matches
Mail list logo
