Re: [PATCH v10 00/38] x86: Secure Memory Encryption (AMD)
On 7/18/2017 7:03 AM, Thomas Gleixner wrote: On Mon, 17 Jul 2017, Tom Lendacky wrote: This patch series provides support for AMD's new Secure Memory Encryption (SME) feature. SME can be used to mark individual pages of memory as encrypted through the page tables. A page of memory that is marked encrypted will be automatically decrypted when read from DRAM and will be automatically encrypted when written to DRAM. Details on SME can found in the links below. The SME feature is identified through a CPUID function and enabled through the SYSCFG MSR. Once enabled, page table entries will determine how the memory is accessed. If a page table entry has the memory encryption mask set, then that memory will be accessed as encrypted memory. The memory encryption mask (as well as other related information) is determined from settings returned through the same CPUID function that identifies the presence of the feature. The approach that this patch series takes is to encrypt everything possible starting early in the boot where the kernel is encrypted. Using the page table macros the encryption mask can be incorporated into all page table entries and page allocations. By updating the protection map, userspace allocations are also marked encrypted. Certain data must be accounted for as having been placed in memory before SME was enabled (EFI, initrd, etc.) and accessed accordingly. This patch series is a pre-cursor to another AMD processor feature called Secure Encrypted Virtualization (SEV). The support for SEV will build upon the SME support and will be submitted later. Details on SEV can be found in the links below. Well done series. Thanks to all people involved, especially Tom and Boris! It was a pleasure to review that. Reviewed-by: Thomas Gleixner A big thanks from me to everyone that helped review this. I truly appreciate all the time that everyone put into this - especially Boris, who helped guide this series from the start. Thanks, Tom -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v10 37/38] compiler-gcc.h: Introduce __nostackp function attribute
On 7/18/2017 4:36 AM, Ingo Molnar wrote:
* Tom Lendacky wrote:
Create a new function attribute, __nostackp, that can used to turn off
stack protection on a per function basis.
Signed-off-by: Tom Lendacky
---
include/linux/compiler-gcc.h | 2 ++
include/linux/compiler.h | 4
2 files changed, 6 insertions(+)
diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
index cd4bbe8..682063b 100644
--- a/include/linux/compiler-gcc.h
+++ b/include/linux/compiler-gcc.h
@@ -166,6 +166,8 @@
#if GCC_VERSION >= 40100
# define __compiletime_object_size(obj) __builtin_object_size(obj, 0)
+
+#define __nostackp __attribute__((__optimize__("no-stack-protector")))
#endif
#if GCC_VERSION >= 40300
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index 219f82f..63cbca1 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -470,6 +470,10 @@ static __always_inline void __write_once_size(volatile
void *p, void *res, int s
#define __visible
#endif
+#ifndef __nostackp
+#define __nostackp
+#endif
So I changed this from the hard to read and ambiguous "__nostackp" abbreviation
(does it mean 'no stack pointer?') to "__nostackprotector", plus added this
detail
to the changelog:
| ( This is needed by the SME in-place kernel memory encryption feature,
| which activates encryption in its sme_enable() function and thus changes the
| visible value of the stack protection cookie on function return. )
Agreed?
Hi Ingo,
I debugged this to needing "__nostackprotector" because sme_enable()
is called very early in the boot process before everything is properly
setup to fully support stack protection when KASLR is enabled. Without
this attribute the call to sme_enable() would fail even if encryption
was disabled with the "mem_encrypt=off" command line option.
If KASLR wasn't enabled, then everything worked fine without the
"__nostackprotector" attribute, encryption enabled or not.
The stack protection support is activated because of the 16-byte
character buffer in the sme_enable() routine. I think we'll find that
if a character buffer greater than 8 bytes is added to, for example,
__startup_64, then this attribute will need to be added to that routine.
Thanks,
Tom
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v10 00/38] x86: Secure Memory Encryption (AMD)
On Mon, 17 Jul 2017, Tom Lendacky wrote: > This patch series provides support for AMD's new Secure Memory Encryption > (SME) > feature. > > SME can be used to mark individual pages of memory as encrypted through the > page tables. A page of memory that is marked encrypted will be automatically > decrypted when read from DRAM and will be automatically encrypted when > written to DRAM. Details on SME can found in the links below. > > The SME feature is identified through a CPUID function and enabled through > the SYSCFG MSR. Once enabled, page table entries will determine how the > memory is accessed. If a page table entry has the memory encryption mask set, > then that memory will be accessed as encrypted memory. The memory encryption > mask (as well as other related information) is determined from settings > returned through the same CPUID function that identifies the presence of the > feature. > > The approach that this patch series takes is to encrypt everything possible > starting early in the boot where the kernel is encrypted. Using the page > table macros the encryption mask can be incorporated into all page table > entries and page allocations. By updating the protection map, userspace > allocations are also marked encrypted. Certain data must be accounted for > as having been placed in memory before SME was enabled (EFI, initrd, etc.) > and accessed accordingly. > > This patch series is a pre-cursor to another AMD processor feature called > Secure Encrypted Virtualization (SEV). The support for SEV will build upon > the SME support and will be submitted later. Details on SEV can be found > in the links below. Well done series. Thanks to all people involved, especially Tom and Boris! It was a pleasure to review that. Reviewed-by: Thomas Gleixner -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v10 37/38] compiler-gcc.h: Introduce __nostackp function attribute
* Tom Lendacky wrote:
> Create a new function attribute, __nostackp, that can used to turn off
> stack protection on a per function basis.
>
> Signed-off-by: Tom Lendacky
> ---
> include/linux/compiler-gcc.h | 2 ++
> include/linux/compiler.h | 4
> 2 files changed, 6 insertions(+)
>
> diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
> index cd4bbe8..682063b 100644
> --- a/include/linux/compiler-gcc.h
> +++ b/include/linux/compiler-gcc.h
> @@ -166,6 +166,8 @@
>
> #if GCC_VERSION >= 40100
> # define __compiletime_object_size(obj) __builtin_object_size(obj, 0)
> +
> +#define __nostackp __attribute__((__optimize__("no-stack-protector")))
> #endif
>
> #if GCC_VERSION >= 40300
> diff --git a/include/linux/compiler.h b/include/linux/compiler.h
> index 219f82f..63cbca1 100644
> --- a/include/linux/compiler.h
> +++ b/include/linux/compiler.h
> @@ -470,6 +470,10 @@ static __always_inline void __write_once_size(volatile
> void *p, void *res, int s
> #define __visible
> #endif
>
> +#ifndef __nostackp
> +#define __nostackp
> +#endif
So I changed this from the hard to read and ambiguous "__nostackp" abbreviation
(does it mean 'no stack pointer?') to "__nostackprotector", plus added this
detail
to the changelog:
| ( This is needed by the SME in-place kernel memory encryption feature,
| which activates encryption in its sme_enable() function and thus changes
the
| visible value of the stack protection cookie on function return. )
Agreed?
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
