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 wrote:
> The
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 f
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
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 en
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 th
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.
Also
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
---
arch/x86/realmo
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 automatica
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 insertions(+), 3 deletions(-)
diff --git a/arch/x8
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
---
arch/x86
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 plac
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 w
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 | 27 ++--
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
---
arch/x86/kernel/kdebugfs.c | 30
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 ++-
arch/x86/kvm/x86.c
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 ++
drivers/gpu/drm/drm_vm.c |4 +
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.
Sign
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 a/drivers/iommu/amd_iommu_init
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
---
arch/x86/include/
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.
Signed-off-b
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.
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 insertions(+)
diff --git a/arch
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
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 b/arch/x86/platform/efi/efi.c
index a15cf81..6407103
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 changed, 40 insertions(+)
diff
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
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 i
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 +++---
3 files changed, 27 ins
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 deletions(-)
diff --git a/arch/x86/
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
---
arch/x86/Kconfig
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.
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
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 rou
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 wi
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 files changed, 68 inserti
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 installed leaf entry at the current level before
> performin
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 conditions to do so
are met (num_entrie
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.
> */
>
> +#def
38 matches
Mail list logo