Re: [PATCH 2/2] iommu: add warning when sharing groups

Hi Alex, On 2/15/2017 4:43 PM, Sinan Kaya wrote: > On 2/15/2017 2:36 PM, Alex Williamson wrote: >> On Tue, 14 Feb 2017 22:53:35 -0500 >> ok...@codeaurora.org wrote: >> >>> On 2017-02-14 18:51, Alex Williamson wrote: On Tue, 14 Feb 2017 16:25:22 -0500 Sinan Kaya

Re: [RFC PATCH v4 03/28] x86: Add the Secure Memory Encryption CPU feature

On Thu, Feb 16, 2017 at 01:42:13PM -0600, Tom Lendacky wrote: > I realize it's a bit more code and expands the changes but I thought it > would be a bit clearer as to what was going on this way. And then the > follow on patch for the physical address reduction goes in nicely, too. Well, the code

Re: [RFC PATCH v4 01/28] x86: Documentation for AMD Secure Memory Encryption (SME)

On 02/16/2017 11:56 AM, Borislav Petkov wrote: > Ok, this time detailed review :-) > > On Thu, Feb 16, 2017 at 09:42:11AM -0600, Tom Lendacky wrote: >> This patch adds a Documenation entry to decribe the AMD Secure Memory >> Encryption (SME) feature. > > Please introduce a spellchecker into your

Re: [RFC PATCH v4 03/28] x86: Add the Secure Memory Encryption CPU feature

On 02/16/2017 12:13 PM, Borislav Petkov wrote: > On Thu, Feb 16, 2017 at 09:42:36AM -0600, Tom Lendacky wrote: >> 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

Re: [RFC PATCH v4 03/28] x86: Add the Secure Memory Encryption CPU feature

On Thu, Feb 16, 2017 at 09:42:36AM -0600, Tom Lendacky wrote: > 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 > SYS_CFG MSR). Only show

Re: [RFC PATCH v4 01/28] x86: Documentation for AMD Secure Memory Encryption (SME)

Ok, this time detailed review :-) On Thu, Feb 16, 2017 at 09:42:11AM -0600, Tom Lendacky wrote: > This patch adds a Documenation entry to decribe the AMD Secure Memory > Encryption (SME) feature. Please introduce a spellchecker into your patch creation workflow. I see two typos in one line.

[RFC PATCH v4 17/28] x86: 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

[RFC PATCH v4 00/28] x86: Secure Memory Encryption (AMD)

This RFC 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

[RFC PATCH v4 02/28] x86: Set the 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

[RFC PATCH v4 27/28] x86: Add support to encrypt the kernel in-place

This patch adds 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 encyrpted by copying the kernel through a temporary buffer. Signed-off-by: Tom Lendacky

[RFC PATCH v4 28/28] x86: Add support to make use of Secure Memory Encryption

This patch adds the 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

[RFC PATCH v4 26/28] x86: 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

[RFC PATCH v4 25/28] x86: Access the setup data through sysfs decrypted

Use memremap() to map the setup data. This will make the appropriate decision as to whether a RAM remapping can be done or if a fallback to ioremap_cache() is needed (similar to the setup data debugfs support). Signed-off-by: Tom Lendacky --- arch/x86/kernel/ksysfs.c |

[RFC PATCH v4 24/28] x86: Access the setup data through debugfs decrypted

Use memremap() to map the setup data. This simplifies the code and will make the appropriate decision as to whether a RAM remapping can be done or if a fallback to ioremap_cache() is needed (which includes checking PageHighMem). Signed-off-by: Tom Lendacky ---

[RFC PATCH v4 23/28] x86/kvm: Enable Secure Memory Encryption of nested page tables

Update the KVM support to include the memory encryption mask when creating and using nested page tables. Signed-off-by: Tom Lendacky --- arch/x86/include/asm/kvm_host.h |3 ++- arch/x86/kvm/mmu.c |8 ++-- arch/x86/kvm/vmx.c |3

[RFC PATCH v4 22/28] x86: 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 + drivers/gpu/drm/drm_gem.c|2 ++

[RFC PATCH v4 21/28] x86: 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 SYS_CFG MSR bit to enable memory encryption on that AP and allow the AP to continue start up.

[RFC PATCH v4 20/28] 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

[RFC PATCH v4 19/28] 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

[RFC PATCH v4 18/28] x86: 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.

[RFC PATCH v4 15/28] 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.

[RFC PATCH v4 16/28] x86: Add support for changing memory encryption attribute

Add support for changing the memory encryption attribute for one or more memory pages. Signed-off-by: Tom Lendacky --- arch/x86/include/asm/cacheflush.h |3 ++ arch/x86/mm/pageattr.c| 66 + 2 files changed, 69

[RFC PATCH v4 14/28] 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 and needs to be mapped decrypted. Add support to apply the proper attributes to the EFI page tables and to the early_memremap and memremap APIs to identify the type of data being accessed so that the proper encryption

[RFC PATCH v4 13/28] efi: Update efi_mem_type() to return defined EFI mem types

Update the efi_mem_type() to return EFI_RESERVED_TYPE instead of a hardcoded 0. Signed-off-by: Tom Lendacky --- arch/x86/platform/efi/efi.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/x86/platform/efi/efi.c

[RFC PATCH v4 12/28] efi: Add an EFI table address match function

This patch adds support 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

[RFC PATCH v4 10/28] x86: 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

[RFC PATCH v4 09/28] x86: Add support for early encryption/decryption 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

[RFC PATCH v4 11/28] x86: Add support to determine the E820 type of an address

This patch adds support to return the E820 type associated with an address range. Signed-off-by: Tom Lendacky --- arch/x86/include/asm/e820/api.h |2 ++ arch/x86/include/asm/e820/types.h |2 ++ arch/x86/kernel/e820.c| 26

[RFC PATCH v4 04/28] x86: Handle reduction in physical address size with SME

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/common.c | 10 +++--- 1 file changed, 7 insertions(+), 3

[RFC PATCH v4 05/28] x86: 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

[RFC PATCH v4 03/28] x86: 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 SYS_CFG MSR). Only show the SME feature as available if reported by CPUID and enabled by BIOS.

[RFC PATCH v4 08/28] x86: Extend the early_memremap support with additional attrs

Add to the 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

[RFC PATCH v4 07/28] x86: Provide general kernel support for memory encryption

Adding general kernel support for memory encryption includes: - Modify and create some page table macros to include the Secure Memory Encryption (SME) memory encryption mask - Modify and create some macros for calculating physical and virtual memory addresses - Provide an SME initialization

[RFC PATCH v4 06/28] x86: Add support to enable SME during early boot processing

This patch adds support to the early boot code to use Secure Memory Encryption (SME). Support is added to update the early pagetables with the memory encryption mask and to encrypt the kernel in place. The routines to set the encryption mask and perform the encryption are stub routines for now

[RFC PATCH v4 01/28] x86: Documentation for AMD Secure Memory Encryption (SME)

This patch adds a Documenation entry to decribe the AMD Secure Memory Encryption (SME) feature. Signed-off-by: Tom Lendacky --- Documentation/admin-guide/kernel-parameters.txt | 11 Documentation/x86/amd-memory-encryption.txt | 57 +++ 2

Re: [RFC PATCH v1] iommu/io-pgtable-arm-v7s: Check for leaf entry right after finding it

Hi, Robin. It would be greatly appreciated if you could test this patch if nobody has objections to the patch itself. On Thu, Feb 16, 2017 at 3:52 PM, Oleksandr Tyshchenko wrote: > From: Oleksandr Tyshchenko > > Do a check for already

[RFC PATCH v1] iommu/io-pgtable-arm-v7s: Check for leaf entry right after finding it

From: Oleksandr Tyshchenko Do a check for already installed leaf entry at the current level before performing any actions when trying to map. This check is already present in arm_v7s_init_pte(), i.e. before installing new leaf entry at the current level if

Re: [PATCH v10 1/9] perf/amd/iommu: Declare pr_fmt and remove unnecessary pr_debug

On Wed, 2017-02-15 at 14:56 -0600, Suravee Suthikulpanit wrote: > Declare pr_fmt for perf/amd_iommu and remove unnecessary pr_debug. [] > diff --git a/arch/x86/events/amd/iommu.c b/arch/x86/events/amd/iommu.c [] > @@ -11,6 +11,8 @@ > * published by the Free Software Foundation. > */ > >