On Mon, 2025-04-21 at 09:51 -0400, Mimi Zohar wrote:
> On Fri, 2025-04-18 at 12:36 +0800, Baoquan He wrote:
> > On 04/15/25 at 07:10pm, steven chen wrote:
> > > From: Steven Chen
> > ^^
>
> As James Bottomley previously explained[1], if you haven't made any changes to
> Tushar's patch, then
Hi,
On 4/21/25 9:26 AM, Ross Philipson wrote:
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 4b9f378e05f6..badde1e9742e 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -2001,6 +2001,17 @@ config EFI_RUNTIME_MAP
>
> See also Documentation/ABI/testing/sysfs-firmwa
From: Ashish Kalra
[ 117.111097] watchdog: BUG: soft lockup - CPU#0 stuck for 27s! [cp:318]
[ 117.15] Modules linked in:
[ 117.20] irq event stamp: 3066414
[ 117.22] hardirqs last enabled at (3066413): []
irqentry_exit+0x39/0x90
[ 117.42] hardirqs last disabled at (3066414)
On 4/21/2025 7:18 AM, Mimi Zohar wrote:
On Mon, 2025-04-21 at 09:51 -0400, Mimi Zohar wrote:
On Fri, 2025-04-18 at 12:36 +0800, Baoquan He wrote:
On 04/15/25 at 07:10pm, steven chen wrote:
From: Steven Chen
^^
As James Bottomley previously explained[1], if you haven't made any changes
On 4/21/25 09:26, Ross Philipson wrote:
> The larger focus of the TrenchBoot project (https://github.com/TrenchBoot) is
> to
> enhance the boot security and integrity in a unified manner.
Hey Folks,
It isn't immediately apparent what these 5,000 lines of code do which is
new, why they are import
On 21/04/2025 9:52 pm, Dave Hansen wrote:
> On 4/21/25 09:26, Ross Philipson wrote:
>> The larger focus of the TrenchBoot project (https://github.com/TrenchBoot)
>> is to
>> enhance the boot security and integrity in a unified manner.
> Hey Folks,
>
> It isn't immediately apparent what these 5,000
On Mon, Apr 21, 2025 at 08:44:53PM +, Ashish Kalra wrote:
> From: Ashish Kalra
>
> [ 117.111097] watchdog: BUG: soft lockup - CPU#0 stuck for 27s! [cp:318]
> [ 117.15] Modules linked in:
> [ 117.20] irq event stamp: 3066414
> [ 117.22] hardirqs last enabled at (3066413): []
On Mon, 2025-04-21 at 13:40 -0700, steven chen wrote:
> On 4/21/2025 7:18 AM, Mimi Zohar wrote:
> > On Mon, 2025-04-21 at 09:51 -0400, Mimi Zohar wrote:
> > > On Fri, 2025-04-18 at 12:36 +0800, Baoquan He wrote:
> > > > On 04/15/25 at 07:10pm, steven chen wrote:
> > > > > From: Steven Chen
> > > >
On 4/21/2025 2:35 PM, Mimi Zohar wrote:
On Mon, 2025-04-21 at 13:40 -0700, steven chen wrote:
On 4/21/2025 7:18 AM, Mimi Zohar wrote:
On Mon, 2025-04-21 at 09:51 -0400, Mimi Zohar wrote:
On Fri, 2025-04-18 at 12:36 +0800, Baoquan He wrote:
On 04/15/25 at 07:10pm, steven chen wrote:
From: Ste
On Fri, 2025-04-18 at 12:36 +0800, Baoquan He wrote:
> On 04/15/25 at 07:10pm, steven chen wrote:
> > From: Steven Chen
> ^^
As James Bottomley previously explained[1], if you haven't made any changes to
Tushar's patch, then the very first line of the patch description would be
"From: Tushar
Quick intro, this is 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 reviewed by one of the x86 folks.
- Patches 5/6 need a review from a lib/cryp
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 4b9f378e05f6..badde
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
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
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 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
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
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
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
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
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
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 | 34 -
drivers/char/tpm/tpm_tis_core.c
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/
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
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
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
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
On 21-04-2025 21:56, Ross Philipson wrote:
The Secure Launch Specification is an architectural agnostic, software neutral
API/ABI maintainted by the TrenchBoot project. It's function is to allow any
typo maintainted
compliant boot loader to communicate the pre-launch configuration to any
c
From: Steven Chen
The current kernel behavior is IMA measurements snapshot is taken at
kexec 'load' and not at kexec 'execute'. IMA log is then carried
over to the new kernel after kexec 'execute'.
Currently, the kernel behavior during kexec load is to fetch the IMA
measurements log from TPM PC
From: Steven Chen
In the current implementation, the ima_dump_measurement_list() API is
called during the kexec "load" phase, where a buffer is allocated and
the measurement records are copied. Due to this, new events added after
kexec load but before kexec execute are not carried over to the n
From: Steven Chen
Before making the function local seq_file "file" variable file static
global, rename it to "ima_kexec_file".
Signed-off-by: Steven Chen
Acked-by: Baoquan He
---
security/integrity/ima/ima_kexec.c | 31 +++---
1 file changed, 16 insertions(+), 15 delet
From: Steven Chen
The amount of memory allocated at kexec load, even with the extra memory
allocated, might not be large enough for the entire measurement list. The
indeterminate interval between kexec 'load' and 'execute' could exacerbate
this problem.
Define two new IMA events, 'kexec_load' a
From: Steven Chen
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 measurements added during
kexec s
On 4/21/25 09:27, Ross Philipson wrote:
> @@ -788,6 +790,9 @@ static void native_machine_halt(void)
>
> tboot_shutdown(TB_SHUTDOWN_HALT);
>
> + /* SEXIT done after machine_shutdown() to meet TXT requirements */
> + slaunch_finalize(1);
This is the kind of stuff that needs to get
From: Steven Chen
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 after
kexec "load'. Setup the needed infrastructure to move the IMA log co
From: Steven Chen
The IMA log is currently copied to the new kernel during kexec 'load' using
ima_dump_measurement_list(). However, the IMA measurement list copied at
kexec 'load' may result in loss of IMA measurements records that only
occurred after the kexec 'load'. Move the IMA measurement
From: Steven Chen
kexec 'load' may be called multiple times. Free and realloc the buffer
only if the segment_size is changed from the previous kexec 'load' call.
Signed-off-by: Steven Chen
Acked-by: Baoquan He
Reviewed-by: Mimi Zohar
---
security/integrity/ima/ima_kexec.c | 10 ++
1
From: Steven Chen
Currently, the function kexec_calculate_store_digests() calculates and
stores the digest of the segment during the kexec_file_load syscall,
where the IMA segment is also allocated.
Later, the IMA segment will be updated with the measurement log at the
kexec execute stage when
From: Steven Chen
Implement kimage_map_segment() to enable IMA to map the measurement log
list to the kimage structure during the kexec 'load' stage. This function
gathers the source pages within the specified address range, and maps them
to a contiguous virtual address range.
This is a prepara
On 4/21/25 09:27, Ross Philipson wrote:
> +static u64 sl_rdmsr(u32 reg)
> +{
> + u64 lo, hi;
> +
> + asm volatile ("rdmsr" : "=a" (lo), "=d" (hi) : "c" (reg));
> +
> + return (hi << 32) | lo;
> +}
Is there a reason this code doesn't just use boot_rdmsr()?
43 matches
Mail list logo
