All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ross Philipson <ross.philipson@oracle.com>
To: Jarkko Sakkinen <jarkko@kernel.org>,
	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
Cc: 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 09/14] x86: Secure Launch SMP bringup support
Date: Thu, 11 May 2023 12:21:22 -0400	[thread overview]
Message-ID: <9fcc3c02-f33a-9d8f-35ea-be8d98fbbd6e@oracle.com> (raw)
In-Reply-To: <CSIYV9UAFYWZ.3KMD32LKER5NS@suppilovahvero>

On 5/10/23 18:55, Jarkko Sakkinen wrote:
> On Thu May 4, 2023 at 5:50 PM EEST, Ross Philipson wrote:
>> 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 parked the APs in a pause/jmp loop waiting for an NMI.
>> The modified SMP boot code is called for the Secure Launch case. The
>> jump address for the RM piggy entry point is fixed up in the jump where
>> the APs are waiting and an NMI IPI is sent to the AP. The AP vectors to
>> the Secure Launch entry point in the RM piggy which mimics what the real
>> mode code would do then jumps to the standard RM piggy protected mode
>> entry point.
>>
>> Signed-off-by: Ross Philipson <ross.philipson@oracle.com>
>> ---
>>   arch/x86/include/asm/realmode.h      |  3 ++
>>   arch/x86/kernel/smpboot.c            | 86 ++++++++++++++++++++++++++++++++++++
>>   arch/x86/realmode/rm/header.S        |  3 ++
>>   arch/x86/realmode/rm/trampoline_64.S | 37 ++++++++++++++++
>>   4 files changed, 129 insertions(+)
>>
>> diff --git a/arch/x86/include/asm/realmode.h b/arch/x86/include/asm/realmode.h
>> index f6a1737..576fe62 100644
>> --- a/arch/x86/include/asm/realmode.h
>> +++ b/arch/x86/include/asm/realmode.h
>> @@ -38,6 +38,9 @@ struct real_mode_header {
>>   #ifdef CONFIG_X86_64
>>   	u32	machine_real_restart_seg;
>>   #endif
>> +#ifdef CONFIG_SECURE_LAUNCH
>> +	u32	sl_trampoline_start32;
>> +#endif
> 
> Cool I was implementing this relocatable realmode blob back in 2012 :-)

It is fun stuff :)

> 
>>   };
>>   
>>   /* This must match data at realmode/rm/trampoline_{32,64}.S */
>> diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
>> index 352f0ce..07d740be 100644
>> --- a/arch/x86/kernel/smpboot.c
>> +++ b/arch/x86/kernel/smpboot.c
>> @@ -57,6 +57,7 @@
>>   #include <linux/pgtable.h>
>>   #include <linux/overflow.h>
>>   #include <linux/stackprotector.h>
>> +#include <linux/slaunch.h>
>>   
>>   #include <asm/acpi.h>
>>   #include <asm/cacheinfo.h>
>> @@ -1068,6 +1069,83 @@ int common_cpu_up(unsigned int cpu, struct task_struct *idle)
>>   	return 0;
>>   }
>>   
>> +#ifdef CONFIG_SECURE_LAUNCH
>> +
>> +static atomic_t first_ap_only = {1};
> 
> This should be documented.

Will do

> 
>> +
>> +/*
>> + * Called to fix the long jump address for the waiting APs to vector to
>> + * the correct startup location in the Secure Launch stub in the rmpiggy.
>> + */
>> +static int
>> +slaunch_fixup_jump_vector(void)
> 
> Please put the same line.

Ack

> 
>> +{
>> +	struct sl_ap_wake_info *ap_wake_info;
>> +	u32 *ap_jmp_ptr = NULL;
>> +
>> +	if (!atomic_dec_and_test(&first_ap_only))
>> +		return 0;
>> +
>> +	ap_wake_info = slaunch_get_ap_wake_info();
>> +
>> +	ap_jmp_ptr = (u32 *)__va(ap_wake_info->ap_wake_block +
>> +				 ap_wake_info->ap_jmp_offset);
>> +
>> +	*ap_jmp_ptr = real_mode_header->sl_trampoline_start32;
>> +
>> +	pr_debug("TXT AP long jump address updated\n");
>> +
>> +	return 0;
>> +}
>> +
>> +/*
>> + * TXT AP startup is quite different than normal. The APs cannot have #INIT
>> + * asserted on them or receive SIPIs. The early Secure Launch code has parked
>> + * the APs in a pause loop waiting to receive an NMI. This will wake the APs
>> + * and have them jump to the protected mode code in the rmpiggy where the rest
>> + * of the SMP boot of the AP will proceed normally.
>> + */
>> +static int
>> +slaunch_wakeup_cpu_from_txt(int cpu, int apicid)
> 
> Ditto.
>

Ack

> 
>> +{
>> +	unsigned long send_status = 0, accept_status = 0;
> 
> I would put these to separate lines. Maybe a matter of taste but
> it is easier to spot initializations.

Sure

> 
>> +
>> +	/* Only done once */
>> +	if (slaunch_fixup_jump_vector())
>> +		return -1;
>> +
>> +	/* Send NMI IPI to idling AP and wake it up */
>> +	apic_icr_write(APIC_DM_NMI, apicid);
>> +
>> +	if (init_udelay == 0)
>> +		udelay(10);
>> +	else
>> +		udelay(300);
>> +
>> +	send_status = safe_apic_wait_icr_idle();
>> +
>> +	if (init_udelay == 0)
>> +		udelay(10);
>> +	else
>> +		udelay(300);
> 
> Magic numbers and no inline comment.

Much of this was copied as is from another function in this module. They 
did not have comments either. I will have to try to track down what 
motivated the delay logic.

> 
>> +
>> +	accept_status = (apic_read(APIC_ESR) & 0xEF);
>> +
>> +	if (send_status)
>> +		pr_err("Secure Launch IPI never delivered???\n");
>> +	if (accept_status)
>> +		pr_err("Secure Launch IPI delivery error (%lx)\n",
>> +			accept_status);
>> +
>> +	return (send_status | accept_status);
>> +}
>> +
>> +#else
>> +
>> +#define slaunch_wakeup_cpu_from_txt(cpu, apicid)	0
>> +
>> +#endif  /* !CONFIG_SECURE_LAUNCH */
>> +
>>   /*
>>    * NOTE - on most systems this is a PHYSICAL apic ID, but on multiquad
>>    * (ie clustered apic addressing mode), this is a LOGICAL apic ID.
>> @@ -1132,6 +1210,13 @@ static int do_boot_cpu(int apicid, int cpu, struct task_struct *idle,
>>   	cpumask_clear_cpu(cpu, cpu_initialized_mask);
>>   	smp_mb();
>>   
>> +	/* With Intel TXT, the AP startup is totally different */
>> +	if ((slaunch_get_flags() & (SL_FLAG_ACTIVE|SL_FLAG_ARCH_TXT)) ==
>> +	   (SL_FLAG_ACTIVE|SL_FLAG_ARCH_TXT)) {
>> +		boot_error = slaunch_wakeup_cpu_from_txt(cpu, apicid);
>> +		goto txt_wake;
>> +	}
>> +
>>   	/*
>>   	 * Wake up a CPU in difference cases:
>>   	 * - Use a method from the APIC driver if one defined, with wakeup
>> @@ -1147,6 +1232,7 @@ static int do_boot_cpu(int apicid, int cpu, struct task_struct *idle,
>>   		boot_error = wakeup_cpu_via_init_nmi(cpu, start_ip, apicid,
>>   						     cpu0_nmi_registered);
>>   
>> +txt_wake:
>>   	if (!boot_error) {
>>   		/*
>>   		 * Wait 10s total for first sign of life from AP
>> diff --git a/arch/x86/realmode/rm/header.S b/arch/x86/realmode/rm/header.S
>> index 2eb62be..3b5cbcb 100644
>> --- a/arch/x86/realmode/rm/header.S
>> +++ b/arch/x86/realmode/rm/header.S
>> @@ -37,6 +37,9 @@ SYM_DATA_START(real_mode_header)
>>   #ifdef CONFIG_X86_64
>>   	.long	__KERNEL32_CS
>>   #endif
>> +#ifdef CONFIG_SECURE_LAUNCH
>> +	.long	pa_sl_trampoline_start32
>> +#endif
>>   SYM_DATA_END(real_mode_header)
>>   
>>   	/* End signature, used to verify integrity */
>> diff --git a/arch/x86/realmode/rm/trampoline_64.S b/arch/x86/realmode/rm/trampoline_64.S
>> index e38d61d..8bb4b0d 100644
>> --- a/arch/x86/realmode/rm/trampoline_64.S
>> +++ b/arch/x86/realmode/rm/trampoline_64.S
>> @@ -104,6 +104,43 @@ SYM_CODE_END(sev_es_trampoline_start)
>>   
>>   	.section ".text32","ax"
>>   	.code32
>> +#ifdef CONFIG_SECURE_LAUNCH
>> +	.balign 4
>> +SYM_CODE_START(sl_trampoline_start32)
>> +	/*
>> +	 * The early secure launch stub AP wakeup code has taken care of all
>> +	 * the vagaries of launching out of TXT. This bit just mimics what the
>> +	 * 16b entry code does and jumps off to the real startup_32.
>> +	 */
>> +	cli
>> +	wbinvd
>> +
>> +	/*
>> +	 * The %ebx provided is not terribly useful since it is the physical
>> +	 * address of tb_trampoline_start and not the base of the image.
>> +	 * Use pa_real_mode_base, which is fixed up, to get a run time
>> +	 * base register to use for offsets to location that do not have
>> +	 * pa_ symbols.
>> +	 */
>> +	movl    $pa_real_mode_base, %ebx
>> +
>> +	/*
>> +	 * This may seem a little odd but this is what %esp would have had in
>> +	 * it on the jmp from real mode because all real mode fixups were done
>> +	 * via the code segment. The base is added at the 32b entry.
>> +	 */
>> +	movl	rm_stack_end, %esp
>> +
>> +	lgdt    tr_gdt(%ebx)
>> +	lidt    tr_idt(%ebx)
>> +
>> +	movw	$__KERNEL_DS, %dx	# Data segment descriptor
>> +
>> +	/* Jump to where the 16b code would have jumped */
>> +	ljmpl	$__KERNEL32_CS, $pa_startup_32
>> +SYM_CODE_END(sl_trampoline_start32)
>> +#endif
>> +
>>   	.balign 4
>>   SYM_CODE_START(startup_32)
>>   	movl	%edx, %ss
>> -- 
>> 1.8.3.1
> 
> 
> The trampoline_64.S changes look reasonable to me (with a quick look).
> 
> BR, Jarkko

Thanks for the review,
Ross

WARNING: multiple messages have this Message-ID (diff)
From: Ross Philipson <ross.philipson@oracle.com>
To: Jarkko Sakkinen <jarkko@kernel.org>,
	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
Cc: 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 09/14] x86: Secure Launch SMP bringup support
Date: Thu, 11 May 2023 12:21:22 -0400	[thread overview]
Message-ID: <9fcc3c02-f33a-9d8f-35ea-be8d98fbbd6e@oracle.com> (raw)
In-Reply-To: <CSIYV9UAFYWZ.3KMD32LKER5NS@suppilovahvero>

On 5/10/23 18:55, Jarkko Sakkinen wrote:
> On Thu May 4, 2023 at 5:50 PM EEST, Ross Philipson wrote:
>> 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 parked the APs in a pause/jmp loop waiting for an NMI.
>> The modified SMP boot code is called for the Secure Launch case. The
>> jump address for the RM piggy entry point is fixed up in the jump where
>> the APs are waiting and an NMI IPI is sent to the AP. The AP vectors to
>> the Secure Launch entry point in the RM piggy which mimics what the real
>> mode code would do then jumps to the standard RM piggy protected mode
>> entry point.
>>
>> Signed-off-by: Ross Philipson <ross.philipson@oracle.com>
>> ---
>>   arch/x86/include/asm/realmode.h      |  3 ++
>>   arch/x86/kernel/smpboot.c            | 86 ++++++++++++++++++++++++++++++++++++
>>   arch/x86/realmode/rm/header.S        |  3 ++
>>   arch/x86/realmode/rm/trampoline_64.S | 37 ++++++++++++++++
>>   4 files changed, 129 insertions(+)
>>
>> diff --git a/arch/x86/include/asm/realmode.h b/arch/x86/include/asm/realmode.h
>> index f6a1737..576fe62 100644
>> --- a/arch/x86/include/asm/realmode.h
>> +++ b/arch/x86/include/asm/realmode.h
>> @@ -38,6 +38,9 @@ struct real_mode_header {
>>   #ifdef CONFIG_X86_64
>>   	u32	machine_real_restart_seg;
>>   #endif
>> +#ifdef CONFIG_SECURE_LAUNCH
>> +	u32	sl_trampoline_start32;
>> +#endif
> 
> Cool I was implementing this relocatable realmode blob back in 2012 :-)

It is fun stuff :)

> 
>>   };
>>   
>>   /* This must match data at realmode/rm/trampoline_{32,64}.S */
>> diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
>> index 352f0ce..07d740be 100644
>> --- a/arch/x86/kernel/smpboot.c
>> +++ b/arch/x86/kernel/smpboot.c
>> @@ -57,6 +57,7 @@
>>   #include <linux/pgtable.h>
>>   #include <linux/overflow.h>
>>   #include <linux/stackprotector.h>
>> +#include <linux/slaunch.h>
>>   
>>   #include <asm/acpi.h>
>>   #include <asm/cacheinfo.h>
>> @@ -1068,6 +1069,83 @@ int common_cpu_up(unsigned int cpu, struct task_struct *idle)
>>   	return 0;
>>   }
>>   
>> +#ifdef CONFIG_SECURE_LAUNCH
>> +
>> +static atomic_t first_ap_only = {1};
> 
> This should be documented.

Will do

> 
>> +
>> +/*
>> + * Called to fix the long jump address for the waiting APs to vector to
>> + * the correct startup location in the Secure Launch stub in the rmpiggy.
>> + */
>> +static int
>> +slaunch_fixup_jump_vector(void)
> 
> Please put the same line.

Ack

> 
>> +{
>> +	struct sl_ap_wake_info *ap_wake_info;
>> +	u32 *ap_jmp_ptr = NULL;
>> +
>> +	if (!atomic_dec_and_test(&first_ap_only))
>> +		return 0;
>> +
>> +	ap_wake_info = slaunch_get_ap_wake_info();
>> +
>> +	ap_jmp_ptr = (u32 *)__va(ap_wake_info->ap_wake_block +
>> +				 ap_wake_info->ap_jmp_offset);
>> +
>> +	*ap_jmp_ptr = real_mode_header->sl_trampoline_start32;
>> +
>> +	pr_debug("TXT AP long jump address updated\n");
>> +
>> +	return 0;
>> +}
>> +
>> +/*
>> + * TXT AP startup is quite different than normal. The APs cannot have #INIT
>> + * asserted on them or receive SIPIs. The early Secure Launch code has parked
>> + * the APs in a pause loop waiting to receive an NMI. This will wake the APs
>> + * and have them jump to the protected mode code in the rmpiggy where the rest
>> + * of the SMP boot of the AP will proceed normally.
>> + */
>> +static int
>> +slaunch_wakeup_cpu_from_txt(int cpu, int apicid)
> 
> Ditto.
>

Ack

> 
>> +{
>> +	unsigned long send_status = 0, accept_status = 0;
> 
> I would put these to separate lines. Maybe a matter of taste but
> it is easier to spot initializations.

Sure

> 
>> +
>> +	/* Only done once */
>> +	if (slaunch_fixup_jump_vector())
>> +		return -1;
>> +
>> +	/* Send NMI IPI to idling AP and wake it up */
>> +	apic_icr_write(APIC_DM_NMI, apicid);
>> +
>> +	if (init_udelay == 0)
>> +		udelay(10);
>> +	else
>> +		udelay(300);
>> +
>> +	send_status = safe_apic_wait_icr_idle();
>> +
>> +	if (init_udelay == 0)
>> +		udelay(10);
>> +	else
>> +		udelay(300);
> 
> Magic numbers and no inline comment.

Much of this was copied as is from another function in this module. They 
did not have comments either. I will have to try to track down what 
motivated the delay logic.

> 
>> +
>> +	accept_status = (apic_read(APIC_ESR) & 0xEF);
>> +
>> +	if (send_status)
>> +		pr_err("Secure Launch IPI never delivered???\n");
>> +	if (accept_status)
>> +		pr_err("Secure Launch IPI delivery error (%lx)\n",
>> +			accept_status);
>> +
>> +	return (send_status | accept_status);
>> +}
>> +
>> +#else
>> +
>> +#define slaunch_wakeup_cpu_from_txt(cpu, apicid)	0
>> +
>> +#endif  /* !CONFIG_SECURE_LAUNCH */
>> +
>>   /*
>>    * NOTE - on most systems this is a PHYSICAL apic ID, but on multiquad
>>    * (ie clustered apic addressing mode), this is a LOGICAL apic ID.
>> @@ -1132,6 +1210,13 @@ static int do_boot_cpu(int apicid, int cpu, struct task_struct *idle,
>>   	cpumask_clear_cpu(cpu, cpu_initialized_mask);
>>   	smp_mb();
>>   
>> +	/* With Intel TXT, the AP startup is totally different */
>> +	if ((slaunch_get_flags() & (SL_FLAG_ACTIVE|SL_FLAG_ARCH_TXT)) ==
>> +	   (SL_FLAG_ACTIVE|SL_FLAG_ARCH_TXT)) {
>> +		boot_error = slaunch_wakeup_cpu_from_txt(cpu, apicid);
>> +		goto txt_wake;
>> +	}
>> +
>>   	/*
>>   	 * Wake up a CPU in difference cases:
>>   	 * - Use a method from the APIC driver if one defined, with wakeup
>> @@ -1147,6 +1232,7 @@ static int do_boot_cpu(int apicid, int cpu, struct task_struct *idle,
>>   		boot_error = wakeup_cpu_via_init_nmi(cpu, start_ip, apicid,
>>   						     cpu0_nmi_registered);
>>   
>> +txt_wake:
>>   	if (!boot_error) {
>>   		/*
>>   		 * Wait 10s total for first sign of life from AP
>> diff --git a/arch/x86/realmode/rm/header.S b/arch/x86/realmode/rm/header.S
>> index 2eb62be..3b5cbcb 100644
>> --- a/arch/x86/realmode/rm/header.S
>> +++ b/arch/x86/realmode/rm/header.S
>> @@ -37,6 +37,9 @@ SYM_DATA_START(real_mode_header)
>>   #ifdef CONFIG_X86_64
>>   	.long	__KERNEL32_CS
>>   #endif
>> +#ifdef CONFIG_SECURE_LAUNCH
>> +	.long	pa_sl_trampoline_start32
>> +#endif
>>   SYM_DATA_END(real_mode_header)
>>   
>>   	/* End signature, used to verify integrity */
>> diff --git a/arch/x86/realmode/rm/trampoline_64.S b/arch/x86/realmode/rm/trampoline_64.S
>> index e38d61d..8bb4b0d 100644
>> --- a/arch/x86/realmode/rm/trampoline_64.S
>> +++ b/arch/x86/realmode/rm/trampoline_64.S
>> @@ -104,6 +104,43 @@ SYM_CODE_END(sev_es_trampoline_start)
>>   
>>   	.section ".text32","ax"
>>   	.code32
>> +#ifdef CONFIG_SECURE_LAUNCH
>> +	.balign 4
>> +SYM_CODE_START(sl_trampoline_start32)
>> +	/*
>> +	 * The early secure launch stub AP wakeup code has taken care of all
>> +	 * the vagaries of launching out of TXT. This bit just mimics what the
>> +	 * 16b entry code does and jumps off to the real startup_32.
>> +	 */
>> +	cli
>> +	wbinvd
>> +
>> +	/*
>> +	 * The %ebx provided is not terribly useful since it is the physical
>> +	 * address of tb_trampoline_start and not the base of the image.
>> +	 * Use pa_real_mode_base, which is fixed up, to get a run time
>> +	 * base register to use for offsets to location that do not have
>> +	 * pa_ symbols.
>> +	 */
>> +	movl    $pa_real_mode_base, %ebx
>> +
>> +	/*
>> +	 * This may seem a little odd but this is what %esp would have had in
>> +	 * it on the jmp from real mode because all real mode fixups were done
>> +	 * via the code segment. The base is added at the 32b entry.
>> +	 */
>> +	movl	rm_stack_end, %esp
>> +
>> +	lgdt    tr_gdt(%ebx)
>> +	lidt    tr_idt(%ebx)
>> +
>> +	movw	$__KERNEL_DS, %dx	# Data segment descriptor
>> +
>> +	/* Jump to where the 16b code would have jumped */
>> +	ljmpl	$__KERNEL32_CS, $pa_startup_32
>> +SYM_CODE_END(sl_trampoline_start32)
>> +#endif
>> +
>>   	.balign 4
>>   SYM_CODE_START(startup_32)
>>   	movl	%edx, %ss
>> -- 
>> 1.8.3.1
> 
> 
> The trampoline_64.S changes look reasonable to me (with a quick look).
> 
> BR, Jarkko

Thanks for the review,
Ross

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

  reply	other threads:[~2023-05-11 16:22 UTC|newest]

Thread overview: 200+ 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 ` 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   ` Ross Philipson
2023-05-04 14:50 ` [PATCH v6 02/14] Documentation/x86: Secure Launch kernel documentation Ross Philipson
2023-05-04 14:50   ` Ross Philipson
2023-05-05 16:19   ` Simon Horman
2023-05-05 16:19     ` Simon Horman
2023-05-05 17:32     ` Ross Philipson
2023-05-05 17:32       ` Ross Philipson
2023-05-06  8:48   ` Bagas Sanjaya
2023-05-06  8:48     ` Bagas Sanjaya
2023-05-10 15:41     ` Ross Philipson
2023-05-10 15:41       ` Ross Philipson
2023-05-12 10:47   ` Matthew Garrett
2023-05-12 10:47     ` Matthew Garrett
2023-06-16 16:44     ` Daniel P. Smith
2023-06-16 16:44       ` Daniel P. Smith
2023-06-16 16:54       ` Matthew Garrett
2023-06-16 16:54         ` Matthew Garrett
2023-06-16 18:21         ` Daniel P. Smith
2023-06-16 18:21           ` Daniel P. Smith
2023-05-12 13:19   ` Thomas Gleixner
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   ` Ross Philipson
2023-05-04 14:50 ` [PATCH v6 04/14] x86: Secure Launch Resource Table header file Ross Philipson
2023-05-04 14:50   ` Ross Philipson
2023-05-05 16:22   ` Simon Horman
2023-05-05 16:22     ` Simon Horman
2023-05-05 17:34     ` Ross Philipson
2023-05-05 17:34       ` Ross Philipson
2023-05-10 23:04   ` Jarkko Sakkinen
2023-05-10 23:04     ` Jarkko Sakkinen
2023-05-15 20:58     ` Daniel P. Smith
2023-05-15 20:58       ` Daniel P. Smith
2023-05-12 10:55   ` Matthew Garrett
2023-05-12 10:55     ` Matthew Garrett
2023-05-15 21:15     ` Daniel P. Smith
2023-05-15 21:15       ` Daniel P. Smith
2023-05-15 21:22       ` Matthew Garrett
2023-05-15 21:22         ` Matthew Garrett
2023-05-16  0:41         ` Daniel P. Smith
2023-05-16  0:41           ` Daniel P. Smith
2023-05-16  1:43           ` Matthew Garrett
2023-05-16  1:43             ` Matthew Garrett
2023-06-16 20:01             ` Daniel P. Smith
2023-06-16 20:01               ` Daniel P. Smith
2023-06-16 20:15               ` Matthew Garrett
2023-06-16 20:15                 ` Matthew Garrett
2023-07-07 19:31                 ` Daniel P. Smith
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-04 14:50   ` Ross Philipson
2023-05-05 16:25   ` Simon Horman
2023-05-05 16:25     ` Simon Horman
2023-05-05 17:37     ` Ross Philipson
2023-05-05 17:37       ` Ross Philipson
2023-05-12 11:00   ` Matthew Garrett
2023-05-12 11:00     ` Matthew Garrett
2023-05-12 16:10     ` Ross Philipson
2023-05-12 16:10       ` Ross Philipson
2023-10-31 21:37       ` 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-04 14:50   ` Ross Philipson
2023-05-05 16:34   ` Simon Horman
2023-05-05 16:34     ` Simon Horman
2023-05-09 16:09     ` Daniel P. Smith
2023-05-09 16:09       ` Daniel P. Smith
2023-05-10  1:21   ` Eric Biggers
2023-05-10  1:21     ` Eric Biggers
2023-05-10 22:28     ` Jarkko Sakkinen
2023-05-10 22:28       ` Jarkko Sakkinen
2023-05-12 11:04     ` Matthew Garrett
2023-05-12 11:04       ` Matthew Garrett
2023-05-12 11:18       ` Ard Biesheuvel
2023-05-12 11:18         ` Ard Biesheuvel
2023-05-12 11:28         ` Matthew Garrett
2023-05-12 11:28           ` Matthew Garrett
2023-05-12 11:58           ` Ard Biesheuvel
2023-05-12 11:58             ` Ard Biesheuvel
2023-05-12 12:24             ` Andrew Cooper
2023-05-12 12:24               ` Andrew Cooper
2023-05-14 18:18               ` Eric Biggers
2023-05-14 18:18                 ` Eric Biggers
2023-05-14 19:11                 ` Matthew Garrett
2023-05-14 19:11                   ` Matthew Garrett
2023-05-12 13:24           ` Thomas Gleixner
2023-05-12 13:24             ` Thomas Gleixner
2023-05-12 16:13             ` Matthew Garrett
2023-05-12 16:13               ` Matthew Garrett
2023-05-12 18:17               ` Thomas Gleixner
2023-05-12 18:17                 ` Thomas Gleixner
2023-05-12 19:12                 ` Matthew Garrett
2023-05-12 19:12                   ` Matthew Garrett
2023-05-12 19:42                   ` Andrew Cooper
2023-05-12 19:42                     ` Andrew Cooper
2023-05-15 21:23     ` Daniel P. Smith
2023-05-15 21:23       ` Daniel P. Smith
2023-05-11  3:33   ` Herbert Xu
2023-05-11  3:33     ` Herbert Xu
2023-05-16  0:50     ` Daniel P. Smith
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-04 14:50   ` Ross Philipson
2023-05-05 17:47   ` Simon Horman
2023-05-05 17:47     ` Simon Horman
2023-05-05 18:58     ` Ross Philipson
2023-05-05 18:58       ` Ross Philipson
2023-05-05 19:46       ` Simon Horman
2023-05-05 19:46         ` Simon Horman
2023-05-12 11:26   ` Matthew Garrett
2023-05-12 11:26     ` Matthew Garrett
2023-05-12 16:17     ` Ross Philipson
2023-05-12 16:17       ` Ross Philipson
2023-05-12 16:27       ` Matthew Garrett
2023-05-12 16:27         ` Matthew Garrett
2023-05-16  1:11       ` Daniel P. Smith
2023-05-16  1:11         ` Daniel P. Smith
2023-05-16  1:45         ` Matthew Garrett
2023-05-16  1:45           ` Matthew Garrett
2023-06-15 18:00           ` Ross Philipson
2023-06-15 18:00             ` Ross Philipson
2023-05-12 18:04   ` Thomas Gleixner
2023-05-12 18:04     ` Thomas Gleixner
2023-05-15 20:13     ` Ross Philipson
2023-05-15 20:13       ` Ross Philipson
2023-09-20 21:40     ` 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-04 14:50   ` Ross Philipson
2023-05-05 17:52   ` Simon Horman
2023-05-05 17:52     ` Simon Horman
2023-05-05 18:59     ` Ross Philipson
2023-05-05 18:59       ` Ross Philipson
2023-05-10 23:02   ` Jarkko Sakkinen
2023-05-10 23:02     ` Jarkko Sakkinen
2023-05-12 15:58     ` Ross Philipson
2023-05-12 15:58       ` Ross Philipson
2023-05-24  2:55       ` Jarkko Sakkinen
2023-05-24  2:55         ` Jarkko Sakkinen
2023-05-12 15:44   ` Thomas Gleixner
2023-05-12 15:44     ` Thomas Gleixner
2023-05-15 20:06     ` Ross Philipson
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-04 14:50   ` Ross Philipson
2023-05-05 17:54   ` Simon Horman
2023-05-05 17:54     ` Simon Horman
2023-05-05 18:59     ` Ross Philipson
2023-05-05 18:59       ` Ross Philipson
2023-05-10 22:55   ` Jarkko Sakkinen
2023-05-10 22:55     ` Jarkko Sakkinen
2023-05-11 16:21     ` Ross Philipson [this message]
2023-05-11 16:21       ` Ross Philipson
2023-05-12 18:02   ` Thomas Gleixner
2023-05-12 18:02     ` Thomas Gleixner
2023-05-15 20:19     ` Ross Philipson
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   ` Ross Philipson
2023-05-04 14:50 ` [PATCH v6 11/14] reboot: Secure Launch SEXIT support on reboot paths Ross Philipson
2023-05-04 14:50   ` Ross Philipson
2023-05-12 11:40   ` Matthew Garrett
2023-05-12 11:40     ` Matthew Garrett
2023-05-15 18:16     ` Ross Philipson
2023-05-15 18:16       ` Ross Philipson
2023-05-16  1:23       ` Daniel P. Smith
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-04 14:50   ` Ross Philipson
2023-05-05 19:42   ` Simon Horman
2023-05-05 19:42     ` Simon Horman
2023-05-08 15:07     ` Ross Philipson
2023-05-08 15:07       ` Ross Philipson
2023-05-10 22:39   ` Jarkko Sakkinen
2023-05-10 22:39     ` Jarkko Sakkinen
2023-05-12 15:53     ` Ross Philipson
2023-05-12 15:53       ` Ross Philipson
2023-05-10 22:40   ` Jarkko Sakkinen
2023-05-10 22:40     ` Jarkko Sakkinen
2023-05-12 15:54     ` Ross Philipson
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-04 14:50   ` Ross Philipson
2023-05-12 11:43   ` Matthew Garrett
2023-05-12 11:43     ` Matthew Garrett
2023-05-12 16:22     ` Ross Philipson
2023-05-12 16:22       ` Ross Philipson
2023-05-16  1:37       ` Daniel P. Smith
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-04 14:50   ` Ross Philipson
2023-05-05  8:39 ` [PATCH v6 00/14] x86: Trenchboot secure dynamic launch Linux kernel support Bagas Sanjaya
2023-05-05  8:39   ` Bagas Sanjaya
2023-05-05 15:45   ` Ross Philipson
2023-05-05 15:45     ` Ross Philipson
2023-05-06  7:56     ` Bagas Sanjaya
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=9fcc3c02-f33a-9d8f-35ea-be8d98fbbd6e@oracle.com \
    --to=ross.philipson@oracle.com \
    --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=jarkko@kernel.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=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.