From: Thomas Gleixner <tglx@linutronix.de> 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, iommu@lists.linux-foundation.org, kexec@lists.infradead.org, linux-efi@vger.kernel.org Cc: ross.philipson@oracle.com, dpsmith@apertussolutions.com, 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: Fri, 12 May 2023 20:02:53 +0200 [thread overview] Message-ID: <87h6shbf76.ffs@tglx> (raw) In-Reply-To: <20230504145023.835096-10-ross.philipson@oracle.com> On Thu, May 04 2023 at 14:50, Ross Philipson wrote: > > +#ifdef CONFIG_SECURE_LAUNCH > + > +static atomic_t first_ap_only = {1}; ATOMIC_INIT(1) if at all. > + > +/* > + * 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) One line please. > +{ > + struct sl_ap_wake_info *ap_wake_info; > + u32 *ap_jmp_ptr = NULL; > + > + if (!atomic_dec_and_test(&first_ap_only)) > + return 0; Why does this need an atomic? CPU bringup is fully serialized and even with the upcoming parallel bootup work, there is no concurrency on this function. Aside of that. Why isn't this initialized during boot in a __init function? > + 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; Why does this need a return code of all return paths 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) > +{ > + unsigned long send_status = 0, accept_status = 0; > + > + /* Only done once */ Yes. But not here. > + 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); The wonders of copy & pasta. This condition is pointless because this code only runs on systems which force init_udelay to 0. > + send_status = safe_apic_wait_icr_idle(); Moar copy & pasta. As this is guaranteed to be X2APIC mode, this function is a nop and returns 0 unconditionally. > + if (init_udelay == 0) > + udelay(10); > + else > + udelay(300); > + > + accept_status = (apic_read(APIC_ESR) & 0xEF); The point of this is? Bit 0-3 are Pentium and P6 only. Bit 4 Tried to send low prio IPI but not supported Bit 5 Illegal Vector sent Bit 6 Illegal Vector received Bit 7 X2APIC illegal register access IOW, there is no accept error here. That would be bit 2 which is never set on anything modern But aside of that the read is moot anyway because the CPU has the APIC error vector enabled so if this would happen the APIC error interrupt would have swallowed and cleared the error condition. IOW. Everything except the apic_icr_write() here is completely useless. > +#else > + > +#define slaunch_wakeup_cpu_from_txt(cpu, apicid) 0 inline stub please. > + > +#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)) { Stick this condition into a helper function please > + 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: Sorry, but what has this to do with TXT ? And why can't the above just be yet another if clause in the existing if/else if maze? Now that brings me to another question. How is this supposed to work with CPU hotplug post boot? It will simply not work at all because once a CPU is offlined it is going to sit in an endless loop and wait for INIT/SIPI/SIPI. So it will get that NMI and go back to wait. So you need a TXT specific cpu_play_dead() implementation, which should preferrably use monitor/mwait where each "offline" CPU sits and waits until a condition becomes true. Then you don't need a NMI for wakeup at all. Just writing the condition into that per CPU cache line should be enough. Thanks, tglx _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
WARNING: multiple messages have this Message-ID (diff)
From: Thomas Gleixner <tglx@linutronix.de> 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, iommu@lists.linux-foundation.org, kexec@lists.infradead.org, linux-efi@vger.kernel.org Cc: ross.philipson@oracle.com, dpsmith@apertussolutions.com, 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: Fri, 12 May 2023 20:02:53 +0200 [thread overview] Message-ID: <87h6shbf76.ffs@tglx> (raw) In-Reply-To: <20230504145023.835096-10-ross.philipson@oracle.com> On Thu, May 04 2023 at 14:50, Ross Philipson wrote: > > +#ifdef CONFIG_SECURE_LAUNCH > + > +static atomic_t first_ap_only = {1}; ATOMIC_INIT(1) if at all. > + > +/* > + * 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) One line please. > +{ > + struct sl_ap_wake_info *ap_wake_info; > + u32 *ap_jmp_ptr = NULL; > + > + if (!atomic_dec_and_test(&first_ap_only)) > + return 0; Why does this need an atomic? CPU bringup is fully serialized and even with the upcoming parallel bootup work, there is no concurrency on this function. Aside of that. Why isn't this initialized during boot in a __init function? > + 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; Why does this need a return code of all return paths 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) > +{ > + unsigned long send_status = 0, accept_status = 0; > + > + /* Only done once */ Yes. But not here. > + 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); The wonders of copy & pasta. This condition is pointless because this code only runs on systems which force init_udelay to 0. > + send_status = safe_apic_wait_icr_idle(); Moar copy & pasta. As this is guaranteed to be X2APIC mode, this function is a nop and returns 0 unconditionally. > + if (init_udelay == 0) > + udelay(10); > + else > + udelay(300); > + > + accept_status = (apic_read(APIC_ESR) & 0xEF); The point of this is? Bit 0-3 are Pentium and P6 only. Bit 4 Tried to send low prio IPI but not supported Bit 5 Illegal Vector sent Bit 6 Illegal Vector received Bit 7 X2APIC illegal register access IOW, there is no accept error here. That would be bit 2 which is never set on anything modern But aside of that the read is moot anyway because the CPU has the APIC error vector enabled so if this would happen the APIC error interrupt would have swallowed and cleared the error condition. IOW. Everything except the apic_icr_write() here is completely useless. > +#else > + > +#define slaunch_wakeup_cpu_from_txt(cpu, apicid) 0 inline stub please. > + > +#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)) { Stick this condition into a helper function please > + 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: Sorry, but what has this to do with TXT ? And why can't the above just be yet another if clause in the existing if/else if maze? Now that brings me to another question. How is this supposed to work with CPU hotplug post boot? It will simply not work at all because once a CPU is offlined it is going to sit in an endless loop and wait for INIT/SIPI/SIPI. So it will get that NMI and go back to wait. So you need a TXT specific cpu_play_dead() implementation, which should preferrably use monitor/mwait where each "offline" CPU sits and waits until a condition becomes true. Then you don't need a NMI for wakeup at all. Just writing the condition into that per CPU cache line should be enough. Thanks, tglx
next prev parent reply other threads:[~2023-05-12 18:03 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 2023-05-11 16:21 ` Ross Philipson 2023-05-12 18:02 ` Thomas Gleixner [this message] 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=87h6shbf76.ffs@tglx \ --to=tglx@linutronix.de \ --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=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: linkBe 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.