Re: [Xen-devel] [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 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [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 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v10 00/38] x86: Secure Memory Encryption (AMD)
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.
The following links provide additional detail:
AMD Memory Encryption whitepaper:
http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2013/12/AMD_Memory_Encryption_Whitepaper_v7-Public.pdf
AMD64 Architecture Programmer's Manual:
http://support.amd.com/TechDocs/24593.pdf
SME is section 7.10
SEV is section 15.34
---
This patch series is based off of the master branch of tip:
https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git master
Commit 5fcfb42b132c ("Merge branch 'linus'")
Source code is also available at https://github.com/codomania/tip/tree/sme-v10
Cc:
Cc: Joerg Roedel
Cc:
Cc:
Cc: Boris Ostrovsky
Cc: Juergen Gross
Still to do:
- Kdump support, including using memremap() instead of ioremap_cache()
Changes since v9:
- Cleared SME feature capability for 32-bit builds
- Added a WARNing to the iounmap() path for ISA ranges to catch callers
which did not use ioremap()
Changes since v8:
- Changed AMD IOMMU SME-related function name
- Updated the sme_encrypt_kernel() entry/exit code to address new warnings
issued by objtool
Changes since v7:
- Fixed kbuild test robot failure related to pgprot_decrypted() macro
usage for some non-x86 archs
- Moved calls to encrypt the kernel and retrieve the encryption mask
from assembler (head_64.S) into C (head64.c)
- Removed use of phys_to_virt() in __ioremap_caller() when address is in
the ISA range. Now regular ioremap() processing occurs.
- Two new, small patches:
- Introduced a native_make_p4d() for use when CONFIG_PGTABLE_LEVELS is
not greater than 4
- Introduced __nostackp GCC option to turn off stack protection on a
per function basis
- General code cleanup based on feedback
Changes since v6:
- Fixed the asm include file issue that caused build errors on other archs
- Rebased the CR3 register changes on top of Andy Lutomirski's patch
- Added a patch to clear the SME cpu feature if running as a PV guest under
Xen
- Added a patch to obtain the AMD microcode level earlier in the boot
instead of directly reading the MSR
- Refactor patch #8 ("x86/mm: Add support to enable SME in early boot
processing") because the 5-level paging support moved the code into the
new C-function __startup_64()
- Removed need to decrypt trampoline area in-place (set memory attributes
before copying the trampoline code)
- General code cleanup based on feedback
Changes since v5:
- Added support for 5-level paging
- Added IOMMU support
- Created a generic asm/mem_encrypt.h in order to remove a bunch of
#ifndef/#define entries
- Removed changes to the __va() macro and defined a function to return
the true physical address in cr3
- Removed sysfs support as it was determined not to be needed
- General code cleanup based on feedback
- General cleanup of patch subjects and descriptions
Changes since v4:
- Re-worked mapping of setup data to not use a fixed list. Rather, check
dynamically whether the requested early_memremap()/memremap() call
needs to be mapped decrypted.
- Moved SME cpu feature into scattered features
- Moved some declarations into header files
- Cleared the encryption mask from the __PHYSICAL_MASK so that users
of macros such as pmd_pfn_mask() don't have to worry/know about the
encryption mask
- Updated some return types and values related to EFI and e820 functions
so that an error could be returned
- During cpu shutdown, removed cache disabling and added a check for kexec
