linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@alien8.de>
To: Tom Lendacky <thomas.lendacky@amd.com>
Cc: linux-arch@vger.kernel.org, linux-efi@vger.kernel.org,
	kvm@vger.kernel.org, linux-doc@vger.kernel.org, x86@kernel.org,
	linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com,
	linux-mm@kvack.org, iommu@lists.linux-foundation.org,
	"Rik van Riel" <riel@redhat.com>,
	"Radim Krčmář" <rkrcmar@redhat.com>,
	"Toshimitsu Kani" <toshi.kani@hpe.com>,
	"Arnd Bergmann" <arnd@arndb.de>,
	"Jonathan Corbet" <corbet@lwn.net>,
	"Matt Fleming" <matt@codeblueprint.co.uk>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	"Joerg Roedel" <joro@8bytes.org>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Brijesh Singh" <brijesh.singh@amd.com>,
	"Ingo Molnar" <mingo@redhat.com>,
	"Alexander Potapenko" <glider@google.com>,
	"Andy Lutomirski" <luto@kernel.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	"Andrey Ryabinin" <aryabinin@virtuozzo.com>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"Larry Woodman" <lwoodman@redhat.com>,
	"Dmitry Vyukov" <dvyukov@google.com>
Subject: Re: [RFC PATCH v4 26/28] x86: Allow kexec to be used with SME
Date: Tue, 28 Feb 2017 11:35:05 +0100	[thread overview]
Message-ID: <20170228103505.yfwwsrwonoztuknl@pd.tnic> (raw)
In-Reply-To: <20170216154755.19244.51276.stgit@tlendack-t1.amdoffice.net>

On Thu, Feb 16, 2017 at 09:47:55AM -0600, Tom Lendacky wrote:
> Provide support so that kexec can be used to boot a kernel when SME is
> enabled.
> 
> Support is needed to allocate pages for kexec without encryption.  This
> is needed in order to be able to reboot in the kernel in the same manner
> as originally booted.
> 
> Additionally, when shutting down all of the CPUs we need to be sure to
> disable caches, flush the caches and then halt. This is needed when booting
> from a state where SME was not active into a state where SME is active.
> Without these steps, it is possible for cache lines to exist for the same
> physical location but tagged both with and without the encryption bit. This
> can cause random memory corruption when caches are flushed depending on
> which cacheline is written last.
> 
> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
> ---
>  arch/x86/include/asm/cacheflush.h    |    2 ++
>  arch/x86/include/asm/init.h          |    1 +
>  arch/x86/include/asm/mem_encrypt.h   |   10 ++++++++
>  arch/x86/include/asm/pgtable_types.h |    1 +
>  arch/x86/kernel/machine_kexec_64.c   |    3 ++
>  arch/x86/kernel/process.c            |   43 +++++++++++++++++++++++++++++++++-
>  arch/x86/kernel/smp.c                |    4 ++-
>  arch/x86/mm/ident_map.c              |    6 +++--
>  arch/x86/mm/pageattr.c               |    2 ++
>  include/linux/mem_encrypt.h          |   10 ++++++++
>  kernel/kexec_core.c                  |   24 +++++++++++++++++++
>  11 files changed, 100 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/x86/include/asm/cacheflush.h b/arch/x86/include/asm/cacheflush.h
> index 33ae60a..2180cd5 100644
> --- a/arch/x86/include/asm/cacheflush.h
> +++ b/arch/x86/include/asm/cacheflush.h
> @@ -48,8 +48,10 @@
>  int set_memory_rw(unsigned long addr, int numpages);
>  int set_memory_np(unsigned long addr, int numpages);
>  int set_memory_4k(unsigned long addr, int numpages);
> +#ifdef CONFIG_AMD_MEM_ENCRYPT
>  int set_memory_encrypted(unsigned long addr, int numpages);
>  int set_memory_decrypted(unsigned long addr, int numpages);
> +#endif
>  
>  int set_memory_array_uc(unsigned long *addr, int addrinarray);
>  int set_memory_array_wc(unsigned long *addr, int addrinarray);

Hmm, why is this ifdeffery creeping in now?

Just supply !CONFIG_AMD_MEM_ENCRYPT versions which don't do anything but
return the address.

> diff --git a/arch/x86/include/asm/init.h b/arch/x86/include/asm/init.h
> index 737da62..b2ec511 100644
> --- a/arch/x86/include/asm/init.h
> +++ b/arch/x86/include/asm/init.h
> @@ -6,6 +6,7 @@ struct x86_mapping_info {
>  	void *context;			 /* context for alloc_pgt_page */
>  	unsigned long pmd_flag;		 /* page flag for PMD entry */
>  	unsigned long offset;		 /* ident mapping offset */
> +	unsigned long kernpg_flag;	 /* kernel pagetable flag override */
>  };
>  
>  int kernel_ident_mapping_init(struct x86_mapping_info *info, pgd_t *pgd_page,
> diff --git a/arch/x86/include/asm/mem_encrypt.h b/arch/x86/include/asm/mem_encrypt.h
> index 5a17f1b..1fd5426 100644
> --- a/arch/x86/include/asm/mem_encrypt.h
> +++ b/arch/x86/include/asm/mem_encrypt.h
> @@ -64,6 +64,16 @@ static inline u64 sme_dma_mask(void)
>  	return 0ULL;
>  }
>  
> +static inline int set_memory_encrypted(unsigned long vaddr, int numpages)
> +{
> +	return 0;
> +}
> +
> +static inline int set_memory_decrypted(unsigned long vaddr, int numpages)
> +{
> +	return 0;
> +}
> +
>  #endif
>  
>  static inline void __init sme_early_encrypt(resource_size_t paddr,
> diff --git a/arch/x86/include/asm/pgtable_types.h b/arch/x86/include/asm/pgtable_types.h
> index f00e70f..456c5cc 100644
> --- a/arch/x86/include/asm/pgtable_types.h
> +++ b/arch/x86/include/asm/pgtable_types.h
> @@ -213,6 +213,7 @@ enum page_cache_mode {
>  #define PAGE_KERNEL		__pgprot(__PAGE_KERNEL | _PAGE_ENC)
>  #define PAGE_KERNEL_RO		__pgprot(__PAGE_KERNEL_RO | _PAGE_ENC)
>  #define PAGE_KERNEL_EXEC	__pgprot(__PAGE_KERNEL_EXEC | _PAGE_ENC)
> +#define PAGE_KERNEL_EXEC_NOENC	__pgprot(__PAGE_KERNEL_EXEC)
>  #define PAGE_KERNEL_RX		__pgprot(__PAGE_KERNEL_RX | _PAGE_ENC)
>  #define PAGE_KERNEL_NOCACHE	__pgprot(__PAGE_KERNEL_NOCACHE | _PAGE_ENC)
>  #define PAGE_KERNEL_LARGE	__pgprot(__PAGE_KERNEL_LARGE | _PAGE_ENC)
> diff --git a/arch/x86/kernel/machine_kexec_64.c b/arch/x86/kernel/machine_kexec_64.c
> index 307b1f4..b01648c 100644
> --- a/arch/x86/kernel/machine_kexec_64.c
> +++ b/arch/x86/kernel/machine_kexec_64.c
> @@ -76,7 +76,7 @@ static int init_transition_pgtable(struct kimage *image, pgd_t *pgd)
>  		set_pmd(pmd, __pmd(__pa(pte) | _KERNPG_TABLE));
>  	}
>  	pte = pte_offset_kernel(pmd, vaddr);
> -	set_pte(pte, pfn_pte(paddr >> PAGE_SHIFT, PAGE_KERNEL_EXEC));
> +	set_pte(pte, pfn_pte(paddr >> PAGE_SHIFT, PAGE_KERNEL_EXEC_NOENC));
>  	return 0;
>  err:
>  	free_transition_pgtable(image);
> @@ -104,6 +104,7 @@ static int init_pgtable(struct kimage *image, unsigned long start_pgtable)
>  		.alloc_pgt_page	= alloc_pgt_page,
>  		.context	= image,
>  		.pmd_flag	= __PAGE_KERNEL_LARGE_EXEC,
> +		.kernpg_flag	= _KERNPG_TABLE_NOENC,
>  	};
>  	unsigned long mstart, mend;
>  	pgd_t *level4p;
> diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
> index 3ed869c..9b01261 100644
> --- a/arch/x86/kernel/process.c
> +++ b/arch/x86/kernel/process.c
> @@ -279,8 +279,43 @@ bool xen_set_default_idle(void)
>  	return ret;
>  }
>  #endif
> -void stop_this_cpu(void *dummy)
> +
> +static bool is_smt_thread(int cpu)
>  {
> +#ifdef CONFIG_SCHED_SMT
> +	if (cpumask_test_cpu(smp_processor_id(), cpu_smt_mask(cpu)))
> +		return true;
> +#endif

No, no sched stuff in here. Just

	if (cpumask_test_cpu(smp_processor_id(), topology_sibling_cpumask(cpu)))


> +	return false;
> +}
> +
> +void stop_this_cpu(void *data)
> +{
> +	atomic_t *stopping_cpu = data;
> +	bool do_cache_disable = false;
> +	bool do_wbinvd = false;
> +
> +	if (stopping_cpu) {
> +		int stopping_id = atomic_read(stopping_cpu);
> +		struct cpuinfo_x86 *c = &cpu_data(stopping_id);
> +
> +		/*
> +		 * If the processor supports SME then we need to clear
> +		 * out cache information before halting it because we could
> +		 * be performing a kexec. With kexec, going from SME
> +		 * inactive to SME active requires clearing cache entries
> +		 * so that addresses without the encryption bit set don't
> +		 * corrupt the same physical address that has the encryption
> +		 * bit set when caches are flushed. If this is not an SMT
> +		 * thread of the stopping CPU then we disable caching at this
> +		 * point to keep the cache clean.
> +		 */
> +		if (cpu_has(c, X86_FEATURE_SME)) {
> +			do_cache_disable = !is_smt_thread(stopping_id);
> +			do_wbinvd = true;
> +		}
> +	}

Let's simplify this (diff ontop of yours). Notice the sme_active() call
in there - I believe we want to do this only when SME is active - not on
any CPU which merely supports SME.

diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index 9b012612698d..e771d7a42e49 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -296,9 +296,6 @@ void stop_this_cpu(void *data)
 	bool do_wbinvd = false;
 
 	if (stopping_cpu) {
-		int stopping_id = atomic_read(stopping_cpu);
-		struct cpuinfo_x86 *c = &cpu_data(stopping_id);
-
 		/*
 		 * If the processor supports SME then we need to clear
 		 * out cache information before halting it because we could
@@ -310,8 +307,8 @@ void stop_this_cpu(void *data)
 		 * thread of the stopping CPU then we disable caching at this
 		 * point to keep the cache clean.
 		 */
-		if (cpu_has(c, X86_FEATURE_SME)) {
-			do_cache_disable = !is_smt_thread(stopping_id);
+		if (sme_active()) {
+			do_cache_disable = !is_smt_thread(atomic_read(stopping_cpu));
 			do_wbinvd = true;
 		}
 	}

>  	local_irq_disable();
>  	/*
>  	 * Remove this CPU:
> @@ -289,6 +324,12 @@ void stop_this_cpu(void *dummy)
>  	disable_local_APIC();
>  	mcheck_cpu_clear(this_cpu_ptr(&cpu_info));
>  
> +	if (do_cache_disable)
> +		write_cr0(read_cr0() | X86_CR0_CD);

Question: what clears CD back again? The CPU online path?

> +
> +	if (do_wbinvd)
> +		wbinvd();
> +

Ok, so this whole shebang is pretty much crippling the machine.
And, AFAICT, you're doing this now from smp_stop_nmi_callback() and
smp_reboot_interrupt() as they both pass a !NULL arg to stop_this_cpu().

And AFAICT those are not all cases where we kexec.

What you need instead, IMO, is __crash_kexec() ->
machine_crash_shutdown() -> native_machine_crash_shutdown() and put all
the SME special handling there.

I *think*.

>  	for (;;)
>  		halt();
>  }

...

> diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
> index 9710f5c..46cc89d 100644
> --- a/arch/x86/mm/pageattr.c
> +++ b/arch/x86/mm/pageattr.c
> @@ -1742,6 +1742,7 @@ int set_memory_4k(unsigned long addr, int numpages)
>  					__pgprot(0), 1, 0, NULL);
>  }
>  
> +#ifdef CONFIG_AMD_MEM_ENCRYPT
>  static int __set_memory_enc_dec(unsigned long addr, int numpages, bool enc)
>  {
>  	struct cpa_data cpa;
> @@ -1807,6 +1808,7 @@ int set_memory_decrypted(unsigned long addr, int numpages)
>  	return __set_memory_enc_dec(addr, numpages, false);
>  }
>  EXPORT_SYMBOL(set_memory_decrypted);
> +#endif	/* CONFIG_AMD_MEM_ENCRYPT */

Btw, I don't see those things used in modules to justify the
EXPORT_SYMBOL(). And it should be EXPORT_SYMBOL_GPL() since it is a new
symbol.

So you could put those wrappers in a header and do the ifdeffery there and
__set_memory_enc_dec() you can do like this:

static int __set_memory_enc_dec(unsigned long addr, int numpages, bool enc)
{
	if (!IS_ENABLED(CONFIG_AMD_MEM_ENCRYPT))
		return 0;

...

}

so that you can save yourself the ifdeffery. The compiler would still
parse the function body so everything else used in there would have to
be defined too, even in the !CONFIG_AMD_MEM_ENCRYPT case.

>  
>  int set_pages_uc(struct page *page, int numpages)
>  {
> diff --git a/include/linux/mem_encrypt.h b/include/linux/mem_encrypt.h
> index 6829ff1..913cf80 100644
> --- a/include/linux/mem_encrypt.h
> +++ b/include/linux/mem_encrypt.h
> @@ -34,6 +34,16 @@ static inline u64 sme_dma_mask(void)
>  	return 0ULL;
>  }
>  
> +static inline int set_memory_encrypted(unsigned long vaddr, int numpages)
> +{
> +	return 0;
> +}
> +
> +static inline int set_memory_decrypted(unsigned long vaddr, int numpages)
> +{
> +	return 0;
> +}
> +
>  #endif
>  
>  #endif	/* CONFIG_AMD_MEM_ENCRYPT */
> diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
> index 5617cc4..ab62f41 100644
> --- a/kernel/kexec_core.c
> +++ b/kernel/kexec_core.c
> @@ -38,6 +38,7 @@
>  #include <linux/syscore_ops.h>
>  #include <linux/compiler.h>
>  #include <linux/hugetlb.h>
> +#include <linux/mem_encrypt.h>
>  
>  #include <asm/page.h>
>  #include <asm/sections.h>
> @@ -315,6 +316,18 @@ static struct page *kimage_alloc_pages(gfp_t gfp_mask, unsigned int order)
>  		count = 1 << order;
>  		for (i = 0; i < count; i++)
>  			SetPageReserved(pages + i);
> +
> +		/*
> +		 * If SME is active we need to be sure that kexec pages are
> +		 * not encrypted because when we boot to the new kernel the
> +		 * pages won't be accessed encrypted (initially).
> +		 */
> +		if (sme_active()) {
> +			void *vaddr = page_address(pages);
> +
> +			set_memory_decrypted((unsigned long)vaddr, count);
> +			memset(vaddr, 0, count * PAGE_SIZE);

Why the memset?

> +		}
>  	}
>  
>  	return pages;
> @@ -326,6 +339,17 @@ static void kimage_free_pages(struct page *page)
>  
>  	order = page_private(page);
>  	count = 1 << order;
> +
> +	/*
> +	 * If SME is active we need to reset the pages back to being an
> +	 * encrypted mapping before freeing them.
> +	 */
> +	if (sme_active()) {
> +		void *vaddr = page_address(page);
> +
> +		set_memory_encrypted((unsigned long)vaddr, count);

        if (sme_active())
                set_memory_encrypted((unsigned long)page_address(page), count);

looks ok to me too.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

  parent reply	other threads:[~2017-02-28 10:40 UTC|newest]

Thread overview: 111+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-16 15:41 [RFC PATCH v4 00/28] x86: Secure Memory Encryption (AMD) Tom Lendacky
2017-02-16 15:42 ` [RFC PATCH v4 01/28] x86: Documentation for AMD Secure Memory Encryption (SME) Tom Lendacky
2017-02-16 17:56   ` Borislav Petkov
2017-02-16 19:48     ` Tom Lendacky
2017-02-16 15:42 ` [RFC PATCH v4 02/28] x86: Set the write-protect cache mode for full PAT support Tom Lendacky
2017-02-17 11:07   ` Borislav Petkov
2017-02-17 15:56     ` Tom Lendacky
2017-02-16 15:42 ` [RFC PATCH v4 03/28] x86: Add the Secure Memory Encryption CPU feature Tom Lendacky
2017-02-16 18:13   ` Borislav Petkov
2017-02-16 19:42     ` Tom Lendacky
2017-02-16 20:06       ` Borislav Petkov
2017-02-16 15:42 ` [RFC PATCH v4 04/28] x86: Handle reduction in physical address size with SME Tom Lendacky
2017-02-17 11:04   ` Borislav Petkov
2017-02-16 15:43 ` [RFC PATCH v4 05/28] x86: Add Secure Memory Encryption (SME) support Tom Lendacky
2017-02-17 12:00   ` Borislav Petkov
2017-02-25 15:29   ` Borislav Petkov
2017-02-28 23:01     ` Tom Lendacky
2017-02-16 15:43 ` [RFC PATCH v4 06/28] x86: Add support to enable SME during early boot processing Tom Lendacky
2017-02-20 12:51   ` Borislav Petkov
2017-02-21 14:55     ` Tom Lendacky
2017-02-21 15:10       ` Borislav Petkov
2017-02-16 15:43 ` [RFC PATCH v4 07/28] x86: Provide general kernel support for memory encryption Tom Lendacky
2017-02-20 15:21   ` Borislav Petkov
2017-02-21 17:18     ` Tom Lendacky
2017-02-22 12:08       ` Borislav Petkov
2017-02-20 18:38   ` Borislav Petkov
2017-02-22 16:43     ` Tom Lendacky
2017-02-22 18:13   ` Dave Hansen
2017-02-23 23:12     ` Tom Lendacky
2017-02-22 18:13   ` Dave Hansen
2017-02-16 15:43 ` [RFC PATCH v4 08/28] x86: Extend the early_memremap support with additional attrs Tom Lendacky
2017-02-20 15:43   ` Borislav Petkov
2017-02-22 15:42     ` Tom Lendacky
2017-02-16 15:43 ` [RFC PATCH v4 09/28] x86: Add support for early encryption/decryption of memory Tom Lendacky
2017-02-20 18:22   ` Borislav Petkov
2017-02-22 15:48     ` Tom Lendacky
2017-02-16 15:44 ` [RFC PATCH v4 10/28] x86: Insure that boot memory areas are mapped properly Tom Lendacky
2017-02-20 19:45   ` Borislav Petkov
2017-02-22 18:34     ` Tom Lendacky
2017-02-16 15:44 ` [RFC PATCH v4 11/28] x86: Add support to determine the E820 type of an address Tom Lendacky
2017-02-20 20:09   ` Borislav Petkov
2017-02-28 22:34     ` Tom Lendacky
2017-03-03  9:52       ` Borislav Petkov
2017-02-16 15:44 ` [RFC PATCH v4 12/28] efi: Add an EFI table address match function Tom Lendacky
2017-02-16 15:44 ` [RFC PATCH v4 13/28] efi: Update efi_mem_type() to return defined EFI mem types Tom Lendacky
2017-02-21 12:05   ` Matt Fleming
2017-02-23 17:27     ` Tom Lendacky
2017-02-24  9:57       ` Matt Fleming
2017-02-16 15:45 ` [RFC PATCH v4 14/28] Add support to access boot related data in the clear Tom Lendacky
2017-02-21 15:06   ` Borislav Petkov
2017-02-23 21:34     ` Tom Lendacky
2017-02-24 10:21       ` Borislav Petkov
2017-02-24 15:04         ` Tom Lendacky
2017-02-24 15:22           ` Borislav Petkov
2017-03-08  6:55   ` Dave Young
2017-03-17 19:50     ` Tom Lendacky
2017-02-16 15:45 ` [RFC PATCH v4 15/28] Add support to access persistent memory " Tom Lendacky
2017-03-17 22:58   ` Elliott, Robert (Persistent Memory)
2017-03-23 21:02     ` Tom Lendacky
2017-02-16 15:45 ` [RFC PATCH v4 16/28] x86: Add support for changing memory encryption attribute Tom Lendacky
2017-02-22 18:52   ` Borislav Petkov
2017-02-28 22:46     ` Tom Lendacky
2017-02-16 15:45 ` [RFC PATCH v4 17/28] x86: Decrypt trampoline area if memory encryption is active Tom Lendacky
2017-02-16 15:46 ` [RFC PATCH v4 18/28] x86: DMA support for memory encryption Tom Lendacky
2017-02-25 17:10   ` Borislav Petkov
2017-03-06 17:47     ` Tom Lendacky
2017-02-16 15:46 ` [RFC PATCH v4 19/28] swiotlb: Add warnings for use of bounce buffers with SME Tom Lendacky
2017-02-17 15:59   ` Konrad Rzeszutek Wilk
2017-02-17 16:51     ` Tom Lendacky
2017-03-02 17:01       ` Paolo Bonzini
2017-02-27 17:52   ` Borislav Petkov
2017-02-28 23:19     ` Tom Lendacky
2017-03-01 11:17       ` Borislav Petkov
2017-02-16 15:46 ` [RFC PATCH v4 20/28] iommu/amd: Disable AMD IOMMU if memory encryption is active Tom Lendacky
2017-02-16 15:46 ` [RFC PATCH v4 21/28] x86: Check for memory encryption on the APs Tom Lendacky
2017-02-27 18:17   ` Borislav Petkov
2017-02-28 23:28     ` Tom Lendacky
2017-03-01 11:17       ` Borislav Petkov
2017-02-16 15:47 ` [RFC PATCH v4 22/28] x86: Do not specify encrypted memory for video mappings Tom Lendacky
2017-02-16 15:47 ` [RFC PATCH v4 23/28] x86/kvm: Enable Secure Memory Encryption of nested page tables Tom Lendacky
2017-02-16 15:47 ` [RFC PATCH v4 24/28] x86: Access the setup data through debugfs decrypted Tom Lendacky
2017-03-08  7:04   ` Dave Young
2017-03-17 19:54     ` Tom Lendacky
2017-02-16 15:47 ` [RFC PATCH v4 25/28] x86: Access the setup data through sysfs decrypted Tom Lendacky
2017-03-08  7:09   ` Dave Young
2017-03-17 20:09     ` Tom Lendacky
2017-02-16 15:47 ` [RFC PATCH v4 26/28] x86: Allow kexec to be used with SME Tom Lendacky
2017-02-17 15:57   ` Konrad Rzeszutek Wilk
2017-02-17 16:43     ` Tom Lendacky
2017-03-01  9:25       ` Dave Young
2017-03-01  9:27         ` Dave Young
2017-03-06 17:58         ` Tom Lendacky
2017-03-06 18:04           ` Tom Lendacky
2017-03-08  8:12           ` Dave Young
2017-02-28 10:35   ` Borislav Petkov [this message]
2017-03-01 15:36     ` Tom Lendacky
2017-02-16 15:48 ` [RFC PATCH v4 27/28] x86: Add support to encrypt the kernel in-place Tom Lendacky
2017-03-01 17:36   ` Borislav Petkov
2017-03-02 18:30     ` Tom Lendacky
2017-03-02 18:51       ` Borislav Petkov
2017-02-16 15:48 ` [RFC PATCH v4 28/28] x86: Add support to make use of Secure Memory Encryption Tom Lendacky
2017-03-01 18:40   ` Borislav Petkov
2017-03-07 16:05     ` Tom Lendacky
2017-03-07 17:42       ` Borislav Petkov
2017-03-08 15:05       ` Borislav Petkov
2017-02-18 18:12 ` [RFC PATCH v4 00/28] x86: Secure Memory Encryption (AMD) Borislav Petkov
2017-02-21 15:09   ` Tom Lendacky
2017-02-21 17:42   ` Rik van Riel
2017-02-21 17:53     ` Borislav Petkov
2017-03-01  9:17 ` Dave Young
2017-03-01 17:51   ` Tom Lendacky

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=20170228103505.yfwwsrwonoztuknl@pd.tnic \
    --to=bp@alien8.de \
    --cc=arnd@arndb.de \
    --cc=aryabinin@virtuozzo.com \
    --cc=brijesh.singh@amd.com \
    --cc=corbet@lwn.net \
    --cc=dvyukov@google.com \
    --cc=glider@google.com \
    --cc=hpa@zytor.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=joro@8bytes.org \
    --cc=kasan-dev@googlegroups.com \
    --cc=konrad.wilk@oracle.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=luto@kernel.org \
    --cc=lwoodman@redhat.com \
    --cc=matt@codeblueprint.co.uk \
    --cc=mingo@redhat.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=riel@redhat.com \
    --cc=rkrcmar@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=thomas.lendacky@amd.com \
    --cc=toshi.kani@hpe.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).