Re: [PATCH v7 03/36] x86, mpparse, x86/acpi, x86/PCI, x86/dmi, SFI: Use memremap for RAM mappings
On Fri, Jun 16, 2017 at 01:50:23PM -0500, Tom Lendacky wrote: > The ioremap() function is intended for mapping MMIO. For RAM, the > memremap() function should 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 mapped > decrypted vs encrypted. > > Signed-off-by: Tom Lendacky > --- > arch/x86/include/asm/dmi.h |8 > arch/x86/kernel/acpi/boot.c |6 +++--- > arch/x86/kernel/kdebugfs.c | 34 +++--- > arch/x86/kernel/ksysfs.c | 28 ++-- > arch/x86/kernel/mpparse.c| 10 +- > arch/x86/pci/common.c|4 ++-- > drivers/firmware/dmi-sysfs.c |5 +++-- > drivers/firmware/pcdp.c |4 ++-- > drivers/sfi/sfi_core.c | 22 +++--- > 9 files changed, 55 insertions(+), 66 deletions(-) Reviewed-by: Borislav Petkov -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply. ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v7 08/36] x86/mm: Add support to enable SME in early boot processing
On Fri, Jun 16, 2017 at 01:51:15PM -0500, Tom Lendacky wrote:
> 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, encrypt
> the kernel in place and update the early pagetables with the memory
> encryption mask so that new pagetable entries will use memory encryption.
>
> The routines to set the encryption mask and perform the encryption are
> stub routines for now with functionality to be added in a later patch.
>
> Because of the need to have the routines available to head_64.S, the
> mem_encrypt.c is always built and #ifdefs in mem_encrypt.c will provide
> functionality or stub routines depending on CONFIG_AMD_MEM_ENCRYPT.
>
> Signed-off-by: Tom Lendacky
> ---
> arch/x86/include/asm/mem_encrypt.h |8 +++
> arch/x86/kernel/head64.c | 33 +-
> arch/x86/kernel/head_64.S | 39
> ++--
> arch/x86/mm/Makefile |4 +---
> arch/x86/mm/mem_encrypt.c | 24 ++
> 5 files changed, 93 insertions(+), 15 deletions(-)
...
> diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c
> index b99d469..9a78277 100644
> --- a/arch/x86/mm/mem_encrypt.c
> +++ b/arch/x86/mm/mem_encrypt.c
> @@ -11,6 +11,9 @@
> */
>
> #include
> +#include
> +
> +#ifdef CONFIG_AMD_MEM_ENCRYPT
>
> /*
> * Since SME related variables are set early in the boot process they must
> @@ -19,3 +22,24 @@
> */
> unsigned long sme_me_mask __section(.data) = 0;
> EXPORT_SYMBOL_GPL(sme_me_mask);
> +
> +void __init sme_encrypt_kernel(void)
> +{
> +}
Just the minor:
void __init sme_encrypt_kernel(void) { }
in case you have to respin.
Reviewed-by: Borislav Petkov
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v7 11/36] x86/mm: Add SME support for read_cr3_pa()
On Fri, Jun 16, 2017 at 01:51:55PM -0500, Tom Lendacky wrote: > The cr3 register entry can contain the SME encryption mask that indicates > the PGD is encrypted. The encryption mask should not be used when > creating a virtual address from the cr3 register, so remove the SME > encryption mask in the read_cr3_pa() function. > > During early boot SME will need to use a native version of read_cr3_pa(), > so create native_read_cr3_pa(). > > Signed-off-by: Tom Lendacky > --- > arch/x86/include/asm/processor-flags.h |3 ++- > arch/x86/include/asm/processor.h |5 + > 2 files changed, 7 insertions(+), 1 deletion(-) Reviewed-by: Borislav Petkov -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply. ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH] s390/crash: Fix KEXEC_NOTE_BYTES definition
Hi Xunlei, [auto build test ERROR on next-20170605] [also build test ERROR on v4.12-rc4] [cannot apply to linus/master linux/master s390/features v4.9-rc8 v4.9-rc7 v4.9-rc6] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Xunlei-Pang/s390-crash-Fix-KEXEC_NOTE_BYTES-definition/20170610-173047 config: arm-sa1100 (attached as .config) compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705 reproduce: wget https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree make.cross ARCH=arm All error/warnings (new ones prefixed by >>): In file included from arch/arm/include/asm/memory.h:378:0, from arch/arm/include/asm/page.h:165, from arch/arm/include/asm/thread_info.h:17, from include/linux/thread_info.h:37, from include/asm-generic/preempt.h:4, from ./arch/arm/include/generated/asm/preempt.h:1, from include/linux/preempt.h:80, from include/linux/spinlock.h:50, from include/linux/seqlock.h:35, from include/linux/time.h:5, from include/linux/efi.h:16, from arch/arm/kernel/setup.c:10: arch/arm/include/asm/kexec.h: In function 'page_to_boot_pfn': >> include/asm-generic/memory_model.h:63:14: error: implicit declaration of >> function 'page_to_section' [-Werror=implicit-function-declaration] int __sec = page_to_section(__pg); \ ^ include/asm-generic/memory_model.h:80:21: note: in expansion of macro '__page_to_pfn' #define page_to_pfn __page_to_pfn ^ arch/arm/include/asm/kexec.h:70:9: note: in expansion of macro 'page_to_pfn' return page_to_pfn(page) + (arch_phys_to_idmap_offset >> PAGE_SHIFT); ^~~ In file included from include/linux/pid_namespace.h:6:0, from include/linux/ptrace.h:9, from include/uapi/linux/elfcore.h:7, from include/linux/elfcore.h:9, from include/linux/crash_core.h:5, from include/linux/kexec.h:27, from arch/arm/kernel/setup.c:24: include/linux/mm.h: At top level: >> include/linux/mm.h:979:29: error: conflicting types for 'page_to_section' static inline unsigned long page_to_section(const struct page *page) ^~~ In file included from arch/arm/include/asm/memory.h:378:0, from arch/arm/include/asm/page.h:165, from arch/arm/include/asm/thread_info.h:17, from include/linux/thread_info.h:37, from include/asm-generic/preempt.h:4, from ./arch/arm/include/generated/asm/preempt.h:1, from include/linux/preempt.h:80, from include/linux/spinlock.h:50, from include/linux/seqlock.h:35, from include/linux/time.h:5, from include/linux/efi.h:16, from arch/arm/kernel/setup.c:10: include/asm-generic/memory_model.h:63:14: note: previous implicit declaration of 'page_to_section' was here int __sec = page_to_section(__pg); \ ^ include/asm-generic/memory_model.h:80:21: note: in expansion of macro '__page_to_pfn' #define page_to_pfn __page_to_pfn ^ arch/arm/include/asm/kexec.h:70:9: note: in expansion of macro 'page_to_pfn' return page_to_pfn(page) + (arch_phys_to_idmap_offset >> PAGE_SHIFT); ^~~ cc1: some warnings being treated as errors -- In file included from arch/arm/include/asm/memory.h:378:0, from arch/arm/include/asm/page.h:165, from arch/arm/include/asm/thread_info.h:17, from include/linux/thread_info.h:37, from include/asm-generic/preempt.h:4, from ./arch/arm/include/generated/asm/preempt.h:1, from include/linux/preempt.h:80, from include/linux/spinlock.h:50, from arch/arm/kernel/traps.c:18: arch/arm/include/asm/kexec.h: In function 'page_to_boot_pfn': >> include/asm-generic/memory_model.h:63:14: error: implicit declaration of >> function 'page_to_section' [-Werror=implicit-function-declaration] int __sec = page_to_section(__pg); \ ^ include/asm-generic/memory_model.h:80:21: note: in expansion of macro '__page_to_pfn' #define page_to_pfn __page_to_pfn ^ arch/arm/include/asm/kexec.h:70:9: note: in expansion of macro 'page_to
Re: [PATCH v7 14/36] x86/mm: Insure that boot memory areas are mapped properly
On Fri, Jun 16, 2017 at 01:52:32PM -0500, Tom Lendacky wrote:
> 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 initrd, encrypt this data in place. Since the future mapping of
> the initrd area will be mapped as encrypted the data will be accessed
> properly.
>
> Signed-off-by: Tom Lendacky
> ---
> arch/x86/include/asm/mem_encrypt.h |6 +++
> arch/x86/include/asm/pgtable.h |3 ++
> arch/x86/kernel/head64.c | 30 +--
> arch/x86/kernel/setup.c|9 +
> arch/x86/mm/kasan_init_64.c|2 +
> arch/x86/mm/mem_encrypt.c | 70
>
> 6 files changed, 115 insertions(+), 5 deletions(-)
...
> diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c
> index b7671b9..ea5e3a6 100644
> --- a/arch/x86/mm/mem_encrypt.c
> +++ b/arch/x86/mm/mem_encrypt.c
> @@ -19,6 +19,8 @@
>
> #include
> #include
> +#include
> +#include
>
> /*
> * Since SME related variables are set early in the boot process they must
> @@ -101,6 +103,74 @@ void __init sme_early_decrypt(resource_size_t paddr,
> unsigned long size)
> __sme_early_enc_dec(paddr, size, false);
> }
>
> +static void __init __sme_early_map_unmap_mem(void *vaddr, unsigned long size,
> + bool map)
> +{
> + unsigned long paddr = (unsigned long)vaddr - __PAGE_OFFSET;
> + pmdval_t pmd_flags, pmd;
> +
> + /* Use early_pmd_flags but remove the encryption mask */
> + pmd_flags = __sme_clr(early_pmd_flags);
> +
> + do {
> + pmd = map ? (paddr & PMD_MASK) + pmd_flags : 0;
> + __early_make_pgtable((unsigned long)vaddr, pmd);
> +
> + vaddr += PMD_SIZE;
> + paddr += PMD_SIZE;
> + size = (size <= PMD_SIZE) ? 0 : size - PMD_SIZE;
> + } while (size);
> +
> + write_cr3(__read_cr3());
local_flush_tlb() or __native_flush_tlb(). Probably the native variant
since this is early fun.
> +}
> +
> +static void __init __sme_map_unmap_bootdata(char *real_mode_data, bool map)
> +{
> + struct boot_params *boot_data;
> + unsigned long cmdline_paddr;
> +
> + /* If SME is not active, the bootdata is in the correct state */
> + if (!sme_active())
> + return;
> +
> + if (!map) {
> + /*
> + * If unmapping, get the command line address before
> + * unmapping the real_mode_data.
> + */
> + boot_data = (struct boot_params *)real_mode_data;
> + cmdline_paddr = boot_data->hdr.cmd_line_ptr |
> + ((u64)boot_data->ext_cmd_line_ptr << 32);
Let it stick out:
cmdline_paddr = bd->hdr.cmd_line_ptr | ((u64)bd->ext_cmd_line_ptr <<
32);
> + }
> +
> + __sme_early_map_unmap_mem(real_mode_data, sizeof(boot_params), map);
> +
> + if (map) {
> + /*
> + * If mapping, get the command line address after mapping
> + * the real_mode_data.
> + */
> + boot_data = (struct boot_params *)real_mode_data;
> + cmdline_paddr = boot_data->hdr.cmd_line_ptr |
> + ((u64)boot_data->ext_cmd_line_ptr << 32);
> + }
> +
> + if (!cmdline_paddr)
> + return;
> +
> + __sme_early_map_unmap_mem(__va(cmdline_paddr), COMMAND_LINE_SIZE, map);
Ok, so from looking at this function now - it does different things
depending on whether we map or not. So it doesn't look like a worker
function anymore and you can move the stuff back to the original callers
below. Should make the whole flow more readable.
> +}
> +
> +void __init sme_unmap_bootdata(char *real_mode_data)
> +{
> + __sme_map_unmap_bootdata(real_mode_data, false);
> +}
> +
> +void __init sme_map_bootdata(char *real_mode_data)
> +{
> + __sme_map_unmap_bootdata(real_mode_data, true);
> +}
> +
> void __init sme_early_init(void)
> {
> unsigned int i;
>
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v7 11/36] x86/mm: Add SME support for read_cr3_pa()
On Fri, Jun 16, 2017 at 11:51 AM, Tom Lendacky wrote: > The cr3 register entry can contain the SME encryption mask that indicates > the PGD is encrypted. The encryption mask should not be used when > creating a virtual address from the cr3 register, so remove the SME > encryption mask in the read_cr3_pa() function. > > During early boot SME will need to use a native version of read_cr3_pa(), > so create native_read_cr3_pa(). > > Signed-off-by: Tom Lendacky > --- > arch/x86/include/asm/processor-flags.h |3 ++- > arch/x86/include/asm/processor.h |5 + > 2 files changed, 7 insertions(+), 1 deletion(-) > > diff --git a/arch/x86/include/asm/processor-flags.h > b/arch/x86/include/asm/processor-flags.h > index 79aa2f9..cb6999c 100644 > --- a/arch/x86/include/asm/processor-flags.h > +++ b/arch/x86/include/asm/processor-flags.h > @@ -2,6 +2,7 @@ > #define _ASM_X86_PROCESSOR_FLAGS_H > > #include > +#include > > #ifdef CONFIG_VM86 > #define X86_VM_MASKX86_EFLAGS_VM > @@ -33,7 +34,7 @@ > */ > #ifdef CONFIG_X86_64 > /* Mask off the address space ID bits. */ > -#define CR3_ADDR_MASK 0x7000ull > +#define CR3_ADDR_MASK __sme_clr(0x7000ull) Can you update the comment one line above, too? ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v7 11/36] x86/mm: Add SME support for read_cr3_pa()
On 6/20/2017 11:17 AM, Andy Lutomirski wrote: On Fri, Jun 16, 2017 at 11:51 AM, Tom Lendacky wrote: The cr3 register entry can contain the SME encryption mask that indicates the PGD is encrypted. The encryption mask should not be used when creating a virtual address from the cr3 register, so remove the SME encryption mask in the read_cr3_pa() function. During early boot SME will need to use a native version of read_cr3_pa(), so create native_read_cr3_pa(). Signed-off-by: Tom Lendacky --- arch/x86/include/asm/processor-flags.h |3 ++- arch/x86/include/asm/processor.h |5 + 2 files changed, 7 insertions(+), 1 deletion(-) diff --git a/arch/x86/include/asm/processor-flags.h b/arch/x86/include/asm/processor-flags.h index 79aa2f9..cb6999c 100644 --- a/arch/x86/include/asm/processor-flags.h +++ b/arch/x86/include/asm/processor-flags.h @@ -2,6 +2,7 @@ #define _ASM_X86_PROCESSOR_FLAGS_H #include +#include #ifdef CONFIG_VM86 #define X86_VM_MASKX86_EFLAGS_VM @@ -33,7 +34,7 @@ */ #ifdef CONFIG_X86_64 /* Mask off the address space ID bits. */ -#define CR3_ADDR_MASK 0x7000ull +#define CR3_ADDR_MASK __sme_clr(0x7000ull) Can you update the comment one line above, too? Yup, will do. Thanks, Tom ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v7 08/36] x86/mm: Add support to enable SME in early boot processing
On 6/20/2017 2:38 AM, Borislav Petkov wrote:
On Fri, Jun 16, 2017 at 01:51:15PM -0500, Tom Lendacky wrote:
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, encrypt
the kernel in place and update the early pagetables with the memory
encryption mask so that new pagetable entries will use memory encryption.
The routines to set the encryption mask and perform the encryption are
stub routines for now with functionality to be added in a later patch.
Because of the need to have the routines available to head_64.S, the
mem_encrypt.c is always built and #ifdefs in mem_encrypt.c will provide
functionality or stub routines depending on CONFIG_AMD_MEM_ENCRYPT.
Signed-off-by: Tom Lendacky
---
arch/x86/include/asm/mem_encrypt.h |8 +++
arch/x86/kernel/head64.c | 33 +-
arch/x86/kernel/head_64.S | 39 ++--
arch/x86/mm/Makefile |4 +---
arch/x86/mm/mem_encrypt.c | 24 ++
5 files changed, 93 insertions(+), 15 deletions(-)
...
diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c
index b99d469..9a78277 100644
--- a/arch/x86/mm/mem_encrypt.c
+++ b/arch/x86/mm/mem_encrypt.c
@@ -11,6 +11,9 @@
*/
#include
+#include
+
+#ifdef CONFIG_AMD_MEM_ENCRYPT
/*
* Since SME related variables are set early in the boot process they must
@@ -19,3 +22,24 @@
*/
unsigned long sme_me_mask __section(.data) = 0;
EXPORT_SYMBOL_GPL(sme_me_mask);
+
+void __init sme_encrypt_kernel(void)
+{
+}
Just the minor:
void __init sme_encrypt_kernel(void) { }
in case you have to respin.
I have to re-spin for the kbuild test error. But given that this
function will be filled in later it's probably not worth doing the
space savings here.
Thanks,
Tom
Reviewed-by: Borislav Petkov
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v7 19/36] x86/mm: Add support to access boot related data in the clear
On Fri, Jun 16, 2017 at 01:53:26PM -0500, Tom Lendacky wrote: > 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. > > Update early_memremap() to provide an arch specific routine to modify the > pagetable protection attributes before they are applied to the new > mapping. This is used to remove the encryption mask for boot related data. > > Update memremap() to provide an arch specific routine to determine if RAM > remapping is allowed. RAM remapping will cause an encrypted mapping to be > generated. By preventing RAM remapping, ioremap_cache() will be used > instead, which will provide a decrypted mapping of the boot related data. > > Signed-off-by: Tom Lendacky > --- > arch/x86/include/asm/io.h |5 + > arch/x86/mm/ioremap.c | 179 > + > include/linux/io.h|2 + > kernel/memremap.c | 20 - > mm/early_ioremap.c| 18 - > 5 files changed, 217 insertions(+), 7 deletions(-) Reviewed-by: Borislav Petkov -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply. ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v7 06/36] x86/mm: Add Secure Memory Encryption (SME) support
On Fri, 16 Jun 2017, Tom Lendacky wrote: > > +config ARCH_HAS_MEM_ENCRYPT > + def_bool y > + depends on X86 That one is silly. The config switch is in the x86 KConfig file, so X86 is on. If you intended to move this to some generic place outside of x86/Kconfig then this should be config ARCH_HAS_MEM_ENCRYPT bool and x86/Kconfig should have select ARCH_HAS_MEM_ENCRYPT and that should be selected by AMD_MEM_ENCRYPT > +config AMD_MEM_ENCRYPT > + bool "AMD Secure Memory Encryption (SME) support" > + depends on X86_64 && CPU_SUP_AMD > + ---help--- > + Say yes to enable support for the encryption of system memory. > + This requires an AMD processor that supports Secure Memory > + Encryption (SME). Thanks, tglx ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v7 07/36] x86/mm: Don't use phys_to_virt in ioremap() if SME is active
On Fri, 16 Jun 2017, Tom Lendacky wrote: > Currently there is a check if the address being mapped is in the ISA > range (is_ISA_range()), and if it is then phys_to_virt() is used to > perform the mapping. When SME is active, however, this will result > in the mapping having the encryption bit set when it is expected that > an ioremap() should not have the encryption bit set. So only use the > phys_to_virt() function if SME is not active This does not make sense to me. What the heck has phys_to_virt() to do with the encryption bit. Especially why would the encryption bit be set on that mapping in the first place? I'm probably missing something, but this want's some coherent explanation understandable by mere mortals both in the changelog and the code comment. Thanks, tglx ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
