[PATCH v5 32/32] x86/mm: Add support to make use of Secure Memory Encryption

Add support to check if SME has been enabled and if memory encryption should be activated (checking of command line option based on the configuration of the default state). If memory encryption is to be activated, then the encryption mask is set and the kernel is encrypted "in place."

[PATCH v5 31/32] x86: Add sysfs support for Secure Memory Encryption

Add sysfs support for SME so that user-space utilities (kdump, etc.) can determine if SME is active. A new directory will be created: /sys/kernel/mm/sme/ And two entries within the new directory: /sys/kernel/mm/sme/active /sys/kernel/mm/sme/encryption_mask Signed-off-by: Tom Lendacky

[PATCH v5 30/32] x86/boot: Add early cmdline parsing for options with arguments

Add a cmdline_find_option() function to look for cmdline options that take arguments. The argument is returned in a supplied buffer and the argument length (regardless of whether it fits in the supplied buffer) is returned, with -1 indicating not found. Signed-off-by: Tom Lendacky

[PATCH v5 29/32] x86/mm: Add support to encrypt the kernel in-place

Add the support to encrypt the kernel in-place. This is done by creating new page mappings for the kernel - a decrypted write-protected mapping and an encrypted mapping. The kernel is encrypted by copying it through a temporary buffer. Signed-off-by: Tom Lendacky ---

[PATCH v5 28/32] x86/mm, kexec: Allow kexec to be used with SME

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

[PATCH v5 27/32] kvm: x86: svm: Enable Secure Memory Encryption within KVM

Update the KVM support to work with SME. The VMCB has a number of fields where physical addresses are used and these addresses must contain the memory encryption mask in order to properly access the encrypted memory. Also, use the memory encryption mask when creating and using the nested page

[PATCH v5 26/32] x86, drm, fbdev: Do not specify encrypted memory for video mappings

Since video memory needs to be accessed decrypted, be sure that the memory encryption mask is not set for the video ranges. Signed-off-by: Tom Lendacky --- arch/x86/include/asm/vga.h | 13 + arch/x86/mm/pageattr.c |2 ++

[PATCH v5 25/32] x86, realmode: Check for memory encryption on the APs

Add support to check if memory encryption is active in the kernel and that it has been enabled on the AP. If memory encryption is active in the kernel but has not been enabled on the AP, then set the memory encryption bit (bit 23) of MSR_K8_SYSCFG to enable memory encryption on that AP and allow

[PATCH v5 23/32] swiotlb: Add warnings for use of bounce buffers with SME

Add warnings to let the user know when bounce buffers are being used for DMA when SME is active. Since the bounce buffers are not in encrypted memory, these notifications are to allow the user to determine some appropriate action - if necessary. Signed-off-by: Tom Lendacky

[PATCH v5 24/32] iommu/amd: Disable AMD IOMMU if memory encryption is active

For now, disable the AMD IOMMU if memory encryption is active. A future patch will re-enable the function with full memory encryption support. Signed-off-by: Tom Lendacky --- drivers/iommu/amd_iommu_init.c |7 +++ 1 file changed, 7 insertions(+) diff --git

[PATCH v5 22/32] x86, swiotlb: DMA support for memory encryption

Since DMA addresses will effectively look like 48-bit addresses when the memory encryption mask is set, SWIOTLB is needed if the DMA mask of the device performing the DMA does not support 48-bits. SWIOTLB will be initialized to create decrypted bounce buffers for use by these devices.

[PATCH v5 21/32] x86, realmode: Decrypt trampoline area if memory encryption is active

When Secure Memory Encryption is enabled, the trampoline area must not be encrypted. A CPU running in real mode will not be able to decrypt memory that has been encrypted because it will not be able to use addresses with the memory encryption mask. Signed-off-by: Tom Lendacky

[PATCH v5 20/32] x86/mm: Add support for changing the memory encryption attribute

Add support for changing the memory encryption attribute for one or more memory pages. This will be useful when we have to change the AP trampoline area to not be encrypted. Or when we need to change the SWIOTLB area to not be encrypted in support of devices that can't support the encryption mask

[PATCH v5 19/32] x86/mm: Add support to access persistent memory in the clear

Persistent memory is expected to persist across reboots. The encryption key used by SME will change across reboots which will result in corrupted persistent memory. Persistent memory is handed out by block devices through memory remapping functions, so be sure not to map this memory as encrypted.

[PATCH v5 18/32] x86, mpparse: Use memremap to map the mpf and mpc data

The SMP MP-table is built by UEFI and placed in memory in a decrypted state. These tables are accessed using a mix of early_memremap(), early_memunmap(), phys_to_virt() and virt_to_phys(). Change all accesses to use early_memremap()/early_memunmap(). This allows for proper setting of the

[PATCH v5 16/32] x86/efi: Update EFI pagetable creation to work with SME

When SME is active, pagetable entries created for EFI need to have the encryption mask set as necessary. When the new pagetable pages are allocated they are mapped encrypted. So, update the efi_pgt value that will be used in cr3 to include the encryption mask so that the PGD table can be read

[PATCH v5 17/32] x86/mm: Add support to access boot related data in the clear

Boot data (such as EFI related data) is not encrypted when the system is booted because UEFI/BIOS does not run with SME active. In order to access this data properly it needs to be mapped decrypted. The early_memremap() support is updated to provide an arch specific routine to modify the

[PATCH v5 15/32] efi: Update efi_mem_type() to return an error rather than 0

The efi_mem_type() function currently returns a 0, which maps to EFI_RESERVED_TYPE, if the function is unable to find a memmap entry for the supplied physical address. Returning EFI_RESERVED_TYPE implies that a memmap entry exists, when it doesn't. Instead of returning 0, change the function to

[PATCH v5 13/32] x86/boot/e820: Add support to determine the E820 type of an address

Add a function that will return the E820 type associated with an address range. Signed-off-by: Tom Lendacky --- arch/x86/include/asm/e820/api.h |2 ++ arch/x86/kernel/e820.c | 26 +++--- 2 files changed, 25 insertions(+), 3

[PATCH v5 10/32] x86/mm: Extend early_memremap() support with additional attrs

Add early_memremap() support to be able to specify encrypted and decrypted mappings with and without write-protection. The use of write-protection is necessary when encrypting data "in place". The write-protect attribute is considered cacheable for loads, but not stores. This implies that the

[PATCH v5 14/32] efi: Add an EFI table address match function

Add a function that will determine if a supplied physical address matches the address of an EFI table. Signed-off-by: Tom Lendacky --- drivers/firmware/efi/efi.c | 33 + include/linux/efi.h|7 +++ 2 files changed, 40

[PATCH v5 12/32] x86/mm: Insure that boot memory areas are mapped properly

The boot data and command line data are present in memory in a decrypted state and are copied early in the boot process. The early page fault support will map these areas as encrypted, so before attempting to copy them, add decrypted mappings so the data is accessed properly when copied. For the

[PATCH v5 11/32] x86/mm: Add support for early encrypt/decrypt of memory

Add support to be able to either encrypt or decrypt data in place during the early stages of booting the kernel. This does not change the memory encryption attribute - it is used for ensuring that data present in either an encrypted or decrypted memory area is in the proper state (for example the

[PATCH v5 09/32] x86/mm: Provide general kernel support for memory encryption

Changes to the existing page table macros will allow the SME support to be enabled in a simple fashion with minimal changes to files that use these macros. Since the memory encryption mask will now be part of the regular pagetable macros, we introduce two new macros (_PAGE_TABLE_NOENC and

[PATCH v5 07/32] x86/mm: Add support to enable SME in early boot processing

Add support to the early boot code to use Secure Memory Encryption (SME). Since the kernel has been loaded into memory in a decrypted state, support is added to encrypt the kernel in place and update the early pagetables with the memory encryption mask so that new pagetable entries will use memory

[PATCH v5 08/32] x86/mm: Simplify p[g4um]d_page() macros

Create a pgd_pfn() and p4d_pfn() macro similar to the p[um]d_pfn() macros and then use the p[g4um]d_pfn() macros in the p[g4um]d_page() macros instead of duplicating the code. Signed-off-by: Tom Lendacky --- arch/x86/include/asm/pgtable.h | 16 +--- 1 file

[PATCH v5 05/32] x86/CPU/AMD: Handle SME reduction in physical address size

When System Memory Encryption (SME) is enabled, the physical address space is reduced. Adjust the x86_phys_bits value to reflect this reduction. Signed-off-by: Tom Lendacky --- arch/x86/kernel/cpu/amd.c | 14 +++--- 1 file changed, 11 insertions(+), 3

[PATCH v5 06/32] x86/mm: Add Secure Memory Encryption (SME) support

Add support for Secure Memory Encryption (SME). This initial support provides a Kconfig entry to build the SME support into the kernel and defines the memory encryption mask that will be used in subsequent patches to mark pages as encrypted. Signed-off-by: Tom Lendacky

[PATCH v5 04/32] x86/CPU/AMD: Add the Secure Memory Encryption CPU feature

Update the CPU features to include identifying and reporting on the Secure Memory Encryption (SME) feature. SME is identified by CPUID 0x801f, but requires BIOS support to enable it (set bit 23 of MSR_K8_SYSCFG). Only show the SME feature as available if reported by CPUID and enabled by

[PATCH v5 03/32] x86, mpparse, x86/acpi, x86/PCI, SFI: Use memremap for RAM mappings

The ioremap() function is intended for mapping MMIO. For RAM, the memremap() function can be used. Convert calls from ioremap() to memremap() when re-mapping RAM. This will be used later by SME to control how the encryption mask is applied to memory mappings, with certain memory locations being

[PATCH v5 02/32] x86/mm/pat: Set write-protect cache mode for full PAT support

For processors that support PAT, set the write-protect cache mode (_PAGE_CACHE_MODE_WP) entry to the actual write-protect value (x05). Acked-by: Borislav Petkov Signed-off-by: Tom Lendacky --- arch/x86/mm/pat.c |6 +++--- 1 file changed, 3

[PATCH v5 00/32] 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

[PATCH v5 01/32] x86: Documentation for AMD Secure Memory Encryption (SME)

Create a Documentation entry to describe the AMD Secure Memory Encryption (SME) feature and add documentation for the mem_encrypt= kernel parameter. Signed-off-by: Tom Lendacky --- Documentation/admin-guide/kernel-parameters.txt | 11

[PATCH v5 06/32] x86/mm: Add Secure Memory Encryption (SME) support

Add support for Secure Memory Encryption (SME). This initial support provides a Kconfig entry to build the SME support into the kernel and defines the memory encryption mask that will be used in subsequent patches to mark pages as encrypted. Signed-off-by: Tom Lendacky

[PATCH v5 05/32] x86/CPU/AMD: Handle SME reduction in physical address size

When System Memory Encryption (SME) is enabled, the physical address space is reduced. Adjust the x86_phys_bits value to reflect this reduction. Signed-off-by: Tom Lendacky --- arch/x86/kernel/cpu/amd.c | 14 +++--- 1 file changed, 11 insertions(+), 3

[PATCH v5 01/32] x86: Documentation for AMD Secure Memory Encryption (SME)

Create a Documentation entry to describe the AMD Secure Memory Encryption (SME) feature and add documentation for the mem_encrypt= kernel parameter. Signed-off-by: Tom Lendacky --- Documentation/admin-guide/kernel-parameters.txt | 11

[PATCH v5 03/32] x86, mpparse, x86/acpi, x86/PCI, SFI: Use memremap for RAM mappings

The ioremap() function is intended for mapping MMIO. For RAM, the memremap() function can be used. Convert calls from ioremap() to memremap() when re-mapping RAM. This will be used later by SME to control how the encryption mask is applied to memory mappings, with certain memory locations being

[PATCH v5 04/32] x86/CPU/AMD: Add the Secure Memory Encryption CPU feature

Update the CPU features to include identifying and reporting on the Secure Memory Encryption (SME) feature. SME is identified by CPUID 0x801f, but requires BIOS support to enable it (set bit 23 of MSR_K8_SYSCFG). Only show the SME feature as available if reported by CPUID and enabled by

[PATCH v5 02/32] x86/mm/pat: Set write-protect cache mode for full PAT support

For processors that support PAT, set the write-protect cache mode (_PAGE_CACHE_MODE_WP) entry to the actual write-protect value (x05). Acked-by: Borislav Petkov Signed-off-by: Tom Lendacky --- arch/x86/mm/pat.c |6 +++--- 1 file changed, 3

[PATCH v5 00/32] 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

Re: [RFC 2/3] virtio-iommu: device probing and operations

On 18/04/17 11:26, Tian, Kevin wrote: >> From: Jean-Philippe Brucker >> Sent: Saturday, April 8, 2017 3:18 AM >> > [...] >> II. Feature bits >> >> >> VIRTIO_IOMMU_F_INPUT_RANGE (0) >> Available range of virtual addresses is described in input_range > > Usually only the

Re: [RFC 1/3] virtio-iommu: firmware description of the virtual topology

On 18/04/17 10:51, Tian, Kevin wrote: >> From: Jean-Philippe Brucker >> Sent: Saturday, April 8, 2017 3:18 AM >> >> Unlike other virtio devices, the virtio-iommu doesn't work independently, >> it is linked to other virtual or assigned devices. So before jumping into >> device operations, we need

[PATCH] iommu: make iommu_bus_notifier return NOTIFY_DONE rather than error code

In iommu_bus_notifier(), when action is BUS_NOTIFY_ADD_DEVICE, it will return 'ops->add_device(dev)' directly. But ops->add_device will return ERR_VAL, such as -ENODEV. These value will make notifier_call_chain() not to traverse the remain nodes in struct notifier_block list. This patch revises

RE: [RFC 2/3] virtio-iommu: device probing and operations

> From: Jean-Philippe Brucker > Sent: Saturday, April 8, 2017 3:18 AM > [...] > II. Feature bits > > > VIRTIO_IOMMU_F_INPUT_RANGE (0) > Available range of virtual addresses is described in input_range Usually only the maximum supported address bits are important. Curious