* SME/32-bit regression @ 2017-09-06 3:45 Boris Ostrovsky 2017-09-06 9:26 ` Borislav Petkov 0 siblings, 1 reply; 13+ messages in thread From: Boris Ostrovsky @ 2017-09-06 3:45 UTC (permalink / raw) To: thomas.lendacky Cc: X86 ML, linux-kernel, Ingo Molnar, H. Peter Anvin, Thomas Gleixner It appears there is a regression for 32-bit kernels due to SME changes. I bisected my particular problem (Xen PV guest) to 21729f81ce8ae76a6995681d40e16f7ce8075db4 but I also saw pmd_clear_bad() errors on baremetal. This seems to be caused by sme_me_mask being an unsigned long as opposed to phys_addr_t (the actual problem is that __PHYSICAL_MASK is truncated). When I declare it as u64 and drop unsigned long cast in __sme_set()/__sme_clr() the problem goes way. (This presumably won't work for non-PAE which I haven't tried). -boris ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: SME/32-bit regression 2017-09-06 3:45 SME/32-bit regression Boris Ostrovsky @ 2017-09-06 9:26 ` Borislav Petkov 2017-09-06 9:45 ` Borislav Petkov 2017-09-06 13:54 ` SME/32-bit regression Boris Ostrovsky 0 siblings, 2 replies; 13+ messages in thread From: Borislav Petkov @ 2017-09-06 9:26 UTC (permalink / raw) To: Boris Ostrovsky Cc: thomas.lendacky, X86 ML, linux-kernel, Ingo Molnar, H. Peter Anvin, Thomas Gleixner On Tue, Sep 05, 2017 at 11:45:07PM -0400, Boris Ostrovsky wrote: > It appears there is a regression for 32-bit kernels due to SME changes. > > I bisected my particular problem It being? Doesn't boot, splats? > (Xen PV guest) to > 21729f81ce8ae76a6995681d40e16f7ce8075db4 but I also saw pmd_clear_bad() > errors on baremetal. This seems to be caused by sme_me_mask being an > unsigned long as opposed to phys_addr_t (the actual problem is that > __PHYSICAL_MASK is truncated). When I declare it as u64 and drop unsigned > long cast in __sme_set()/__sme_clr() the problem goes way. (This presumably > won't work for non-PAE which I haven't tried). Right, so I think we should do this because those macros should not have any effect on !CONFIG_AMD_MEM_ENCRYPT setups. --- diff --git a/include/linux/mem_encrypt.h b/include/linux/mem_encrypt.h index 1255f09f5e42..823eec6ba951 100644 --- a/include/linux/mem_encrypt.h +++ b/include/linux/mem_encrypt.h @@ -35,6 +35,7 @@ static inline unsigned long sme_get_me_mask(void) return sme_me_mask; } +#ifdef CONFIG_AMD_MEM_ENCRYPT /* * The __sme_set() and __sme_clr() macros are useful for adding or removing * the encryption mask from a value (e.g. when dealing with pagetable @@ -42,6 +43,10 @@ static inline unsigned long sme_get_me_mask(void) */ #define __sme_set(x) ((unsigned long)(x) | sme_me_mask) #define __sme_clr(x) ((unsigned long)(x) & ~sme_me_mask) +#else +#define __sme_set(x) (x) +#define __sme_clr(x) (x) +#endif #endif /* __ASSEMBLY__ */ -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply. ^ permalink raw reply related [flat|nested] 13+ messages in thread
* Re: SME/32-bit regression 2017-09-06 9:26 ` Borislav Petkov @ 2017-09-06 9:45 ` Borislav Petkov [not found] ` <CY4PR12MB11415936E980489690575E65EC970@CY4PR12MB1141.namprd12.prod.outlook.com> 2017-09-06 13:54 ` SME/32-bit regression Boris Ostrovsky 1 sibling, 1 reply; 13+ messages in thread From: Borislav Petkov @ 2017-09-06 9:45 UTC (permalink / raw) To: Tom Lendacky Cc: Boris Ostrovsky, thomas.lendacky, X86 ML, linux-kernel, Ingo Molnar, H. Peter Anvin, Thomas Gleixner Btw, Tom, pls remind me again, why didn't we make sme_me_mask u64? Because this is the most logical type for a memory encryption mask which covers 64 bits... In any case, the below builds fine here. --- diff --git a/arch/x86/include/asm/mem_encrypt.h b/arch/x86/include/asm/mem_encrypt.h index 8e618fcf1f7c..6a77c63540f7 100644 --- a/arch/x86/include/asm/mem_encrypt.h +++ b/arch/x86/include/asm/mem_encrypt.h @@ -21,7 +21,7 @@ #ifdef CONFIG_AMD_MEM_ENCRYPT -extern unsigned long sme_me_mask; +extern u64 sme_me_mask; void sme_encrypt_execute(unsigned long encrypted_kernel_vaddr, unsigned long decrypted_kernel_vaddr, @@ -49,7 +49,7 @@ void swiotlb_set_mem_attributes(void *vaddr, unsigned long size); #else /* !CONFIG_AMD_MEM_ENCRYPT */ -#define sme_me_mask 0UL +#define sme_me_mask 0ULL static inline void __init sme_early_encrypt(resource_size_t paddr, unsigned long size) { } diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c index 0fbd09269757..3fcc8e01683b 100644 --- a/arch/x86/mm/mem_encrypt.c +++ b/arch/x86/mm/mem_encrypt.c @@ -37,7 +37,7 @@ static char sme_cmdline_off[] __initdata = "off"; * reside in the .data section so as not to be zeroed out when the .bss * section is later cleared. */ -unsigned long sme_me_mask __section(.data) = 0; +u64 sme_me_mask __section(.data) = 0; EXPORT_SYMBOL_GPL(sme_me_mask); /* Buffer used for early in-place encryption by BSP, no locking needed */ diff --git a/include/linux/mem_encrypt.h b/include/linux/mem_encrypt.h index 1255f09f5e42..265a9cd21cb4 100644 --- a/include/linux/mem_encrypt.h +++ b/include/linux/mem_encrypt.h @@ -21,7 +21,7 @@ #else /* !CONFIG_ARCH_HAS_MEM_ENCRYPT */ -#define sme_me_mask 0UL +#define sme_me_mask 0ULL #endif /* CONFIG_ARCH_HAS_MEM_ENCRYPT */ @@ -30,18 +30,23 @@ static inline bool sme_active(void) return !!sme_me_mask; } -static inline unsigned long sme_get_me_mask(void) +static inline u64 sme_get_me_mask(void) { return sme_me_mask; } +#ifdef CONFIG_AMD_MEM_ENCRYPT /* * The __sme_set() and __sme_clr() macros are useful for adding or removing * the encryption mask from a value (e.g. when dealing with pagetable * entries). */ -#define __sme_set(x) ((unsigned long)(x) | sme_me_mask) -#define __sme_clr(x) ((unsigned long)(x) & ~sme_me_mask) +#define __sme_set(x) ((x) | sme_me_mask) +#define __sme_clr(x) ((x) & ~sme_me_mask) +#else +#define __sme_set(x) (x) +#define __sme_clr(x) (x) +#endif #endif /* __ASSEMBLY__ */ -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply. ^ permalink raw reply related [flat|nested] 13+ messages in thread
[parent not found: <CY4PR12MB11415936E980489690575E65EC970@CY4PR12MB1141.namprd12.prod.outlook.com>]
* Re: SME/32-bit regression [not found] ` <CY4PR12MB11415936E980489690575E65EC970@CY4PR12MB1141.namprd12.prod.outlook.com> @ 2017-09-06 16:44 ` Borislav Petkov 2017-09-06 18:06 ` Brijesh Singh 0 siblings, 1 reply; 13+ messages in thread From: Borislav Petkov @ 2017-09-06 16:44 UTC (permalink / raw) To: Lendacky, Thomas Cc: Boris Ostrovsky, X86 ML, linux-kernel, Ingo Molnar, H. Peter Anvin, Thomas Gleixner, Singh, Brijesh On Wed, Sep 06, 2017 at 04:30:23PM +0000, Lendacky, Thomas wrote: > Sorry for the top post, I'm on holiday and don't have access to a good > email client... I went with unsigned long to match all the page table > related declarations. If changing to u64 doesn't generate any warnings > or other issues them I'm good with that. Ok, no worries. Lemme run the smoke-tests on it and test it to see everything else still works. Thx. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: SME/32-bit regression 2017-09-06 16:44 ` Borislav Petkov @ 2017-09-06 18:06 ` Brijesh Singh 2017-09-06 18:19 ` Borislav Petkov 0 siblings, 1 reply; 13+ messages in thread From: Brijesh Singh @ 2017-09-06 18:06 UTC (permalink / raw) To: Borislav Petkov, Lendacky, Thomas Cc: brijesh.singh, Boris Ostrovsky, X86 ML, linux-kernel, Ingo Molnar, H. Peter Anvin, Thomas Gleixner On 09/06/2017 11:44 AM, Borislav Petkov wrote: > On Wed, Sep 06, 2017 at 04:30:23PM +0000, Lendacky, Thomas wrote: >> Sorry for the top post, I'm on holiday and don't have access to a good >> email client... I went with unsigned long to match all the page table >> related declarations. If changing to u64 doesn't generate any warnings >> or other issues them I'm good with that. > > Ok, no worries. Lemme run the smoke-tests on it and test it to see > everything else still works. > I did the following quick run with your patch and everything seems to be working okay 64-bit build: ------- 1) Baremetal SME *enabled* - System boots fine a) 32-bit guest launch : successful (KVM HV) b) 64-bit guest launch : successful (KVM HV) c) 64-bit SEV guest launch : successful (KVM HV) 2) Baremetal SME *disabled* - System boots fine a) 32-bit guest launch : successful (KVM HV) b) 64-bit guest launch : successful (KVM HV) c) 64-bit SEV guest launch : successful (KVM HV) 32-bit build ---------- I am installing 32-bit distro to verify 32-bit baremetal boot and will report my findings soon. -Brijesh ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: SME/32-bit regression 2017-09-06 18:06 ` Brijesh Singh @ 2017-09-06 18:19 ` Borislav Petkov 2017-09-06 21:03 ` Boris Ostrovsky 0 siblings, 1 reply; 13+ messages in thread From: Borislav Petkov @ 2017-09-06 18:19 UTC (permalink / raw) To: Brijesh Singh Cc: Lendacky, Thomas, Boris Ostrovsky, X86 ML, linux-kernel, Ingo Molnar, H. Peter Anvin, Thomas Gleixner On Wed, Sep 06, 2017 at 01:06:50PM -0500, Brijesh Singh wrote: > I did the following quick run with your patch and everything seems to be > working okay > > 64-bit build: > ------- > 1) Baremetal SME *enabled* - System boots fine > a) 32-bit guest launch : successful (KVM HV) > b) 64-bit guest launch : successful (KVM HV) > c) 64-bit SEV guest launch : successful (KVM HV) > > 2) Baremetal SME *disabled* - System boots fine > a) 32-bit guest launch : successful (KVM HV) > b) 64-bit guest launch : successful (KVM HV) > c) 64-bit SEV guest launch : successful (KVM HV) > > 32-bit build > ---------- > I am installing 32-bit distro to verify 32-bit baremetal boot and will > report my findings soon. Thanks Brijesh, that's awesome! I'll add your Tested-by once you're done testing successfully. :-) -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: SME/32-bit regression 2017-09-06 18:19 ` Borislav Petkov @ 2017-09-06 21:03 ` Boris Ostrovsky 2017-09-07 0:26 ` Brijesh Singh 0 siblings, 1 reply; 13+ messages in thread From: Boris Ostrovsky @ 2017-09-06 21:03 UTC (permalink / raw) To: Borislav Petkov, Brijesh Singh Cc: Lendacky, Thomas, X86 ML, linux-kernel, Ingo Molnar, H. Peter Anvin, Thomas Gleixner On 09/06/2017 02:19 PM, Borislav Petkov wrote: > On Wed, Sep 06, 2017 at 01:06:50PM -0500, Brijesh Singh wrote: >> I did the following quick run with your patch and everything seems to be >> working okay >> >> 64-bit build: >> ------- >> 1) Baremetal SME *enabled* - System boots fine >> a) 32-bit guest launch : successful (KVM HV) >> b) 64-bit guest launch : successful (KVM HV) >> c) 64-bit SEV guest launch : successful (KVM HV) >> >> 2) Baremetal SME *disabled* - System boots fine >> a) 32-bit guest launch : successful (KVM HV) >> b) 64-bit guest launch : successful (KVM HV) >> c) 64-bit SEV guest launch : successful (KVM HV) >> >> 32-bit build >> ---------- >> I am installing 32-bit distro to verify 32-bit baremetal boot and will >> report my findings soon. > Thanks Brijesh, that's awesome! > > I'll add your Tested-by once you're done testing successfully. You can have my Tested-by (mostly Xen but some baremetal too). -boris ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: SME/32-bit regression 2017-09-06 21:03 ` Boris Ostrovsky @ 2017-09-07 0:26 ` Brijesh Singh 2017-09-07 9:38 ` [PATCH] x86/mm: Make the SME mask a u64 Borislav Petkov 0 siblings, 1 reply; 13+ messages in thread From: Brijesh Singh @ 2017-09-07 0:26 UTC (permalink / raw) To: Boris Ostrovsky, Borislav Petkov Cc: brijesh.singh, Lendacky, Thomas, X86 ML, linux-kernel, Ingo Molnar, H. Peter Anvin, Thomas Gleixner On 09/06/2017 04:03 PM, Boris Ostrovsky wrote: > On 09/06/2017 02:19 PM, Borislav Petkov wrote: >> On Wed, Sep 06, 2017 at 01:06:50PM -0500, Brijesh Singh wrote: >>> I did the following quick run with your patch and everything seems to be >>> working okay >>> >>> 64-bit build: >>> ------- >>> 1) Baremetal SME *enabled* - System boots fine >>> a) 32-bit guest launch : successful (KVM HV) >>> b) 64-bit guest launch : successful (KVM HV) >>> c) 64-bit SEV guest launch : successful (KVM HV) >>> >>> 2) Baremetal SME *disabled* - System boots fine >>> a) 32-bit guest launch : successful (KVM HV) >>> b) 64-bit guest launch : successful (KVM HV) >>> c) 64-bit SEV guest launch : successful (KVM HV) >>> >>> 32-bit build >>> ---------- >>> I am installing 32-bit distro to verify 32-bit baremetal boot and will >>> report my findings soon. >> Thanks Brijesh, that's awesome! >> >> I'll add your Tested-by once you're done testing successfully. > 32-bit seems to be working well - thanks -Brijesh > > You can have my Tested-by (mostly Xen but some baremetal too). > > -boris > ^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH] x86/mm: Make the SME mask a u64 2017-09-07 0:26 ` Brijesh Singh @ 2017-09-07 9:38 ` Borislav Petkov 2017-09-07 10:34 ` [tip:x86/urgent] " tip-bot for Borislav Petkov 0 siblings, 1 reply; 13+ messages in thread From: Borislav Petkov @ 2017-09-07 9:38 UTC (permalink / raw) To: x86-ml Cc: Brijesh Singh, Boris Ostrovsky, Lendacky, Thomas, linux-kernel, Ingo Molnar, H. Peter Anvin, Thomas Gleixner On Wed, Sep 06, 2017 at 07:26:40PM -0500, Brijesh Singh wrote: > 32-bit seems to be working well - thanks Thanks Boris and Brijesh for testing! --- From: Borislav Petkov <bp@suse.de> The SME encryption mask is for masking 64-bit pagetable entries. It being an unsigned long works fine on X86_64 but on 32-bit builds in truncates bits leading to Xen guests crashing very early. And regardless, the whole SME mask handling shouldnt've leaked into 32-bit because SME is X86_64-only feature. So, first make the mask u64. And then, add trivial 32-bit versions of the __sme_* macros so that nothing happens there. Reported-and-tested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Tested-by: Brijesh Singh <brijesh.singh@amd.com> Signed-off-by: Borislav Petkov <bp@suse.de> Acked-by: Tom Lendacky <Thomas.Lendacky@amd.com> Fixes: 21729f81ce8a ("x86/mm: Provide general kernel support for memory encryption") --- arch/x86/include/asm/mem_encrypt.h | 4 ++-- arch/x86/mm/mem_encrypt.c | 2 +- include/linux/mem_encrypt.h | 13 +++++++++---- 3 files changed, 12 insertions(+), 7 deletions(-) diff --git a/arch/x86/include/asm/mem_encrypt.h b/arch/x86/include/asm/mem_encrypt.h index 8e618fcf1f7c..6a77c63540f7 100644 --- a/arch/x86/include/asm/mem_encrypt.h +++ b/arch/x86/include/asm/mem_encrypt.h @@ -21,7 +21,7 @@ #ifdef CONFIG_AMD_MEM_ENCRYPT -extern unsigned long sme_me_mask; +extern u64 sme_me_mask; void sme_encrypt_execute(unsigned long encrypted_kernel_vaddr, unsigned long decrypted_kernel_vaddr, @@ -49,7 +49,7 @@ void swiotlb_set_mem_attributes(void *vaddr, unsigned long size); #else /* !CONFIG_AMD_MEM_ENCRYPT */ -#define sme_me_mask 0UL +#define sme_me_mask 0ULL static inline void __init sme_early_encrypt(resource_size_t paddr, unsigned long size) { } diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c index 0fbd09269757..3fcc8e01683b 100644 --- a/arch/x86/mm/mem_encrypt.c +++ b/arch/x86/mm/mem_encrypt.c @@ -37,7 +37,7 @@ static char sme_cmdline_off[] __initdata = "off"; * reside in the .data section so as not to be zeroed out when the .bss * section is later cleared. */ -unsigned long sme_me_mask __section(.data) = 0; +u64 sme_me_mask __section(.data) = 0; EXPORT_SYMBOL_GPL(sme_me_mask); /* Buffer used for early in-place encryption by BSP, no locking needed */ diff --git a/include/linux/mem_encrypt.h b/include/linux/mem_encrypt.h index 1255f09f5e42..265a9cd21cb4 100644 --- a/include/linux/mem_encrypt.h +++ b/include/linux/mem_encrypt.h @@ -21,7 +21,7 @@ #else /* !CONFIG_ARCH_HAS_MEM_ENCRYPT */ -#define sme_me_mask 0UL +#define sme_me_mask 0ULL #endif /* CONFIG_ARCH_HAS_MEM_ENCRYPT */ @@ -30,18 +30,23 @@ static inline bool sme_active(void) return !!sme_me_mask; } -static inline unsigned long sme_get_me_mask(void) +static inline u64 sme_get_me_mask(void) { return sme_me_mask; } +#ifdef CONFIG_AMD_MEM_ENCRYPT /* * The __sme_set() and __sme_clr() macros are useful for adding or removing * the encryption mask from a value (e.g. when dealing with pagetable * entries). */ -#define __sme_set(x) ((unsigned long)(x) | sme_me_mask) -#define __sme_clr(x) ((unsigned long)(x) & ~sme_me_mask) +#define __sme_set(x) ((x) | sme_me_mask) +#define __sme_clr(x) ((x) & ~sme_me_mask) +#else +#define __sme_set(x) (x) +#define __sme_clr(x) (x) +#endif #endif /* __ASSEMBLY__ */ -- 2.13.0 -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply. ^ permalink raw reply related [flat|nested] 13+ messages in thread
* [tip:x86/urgent] x86/mm: Make the SME mask a u64 2017-09-07 9:38 ` [PATCH] x86/mm: Make the SME mask a u64 Borislav Petkov @ 2017-09-07 10:34 ` tip-bot for Borislav Petkov 0 siblings, 0 replies; 13+ messages in thread From: tip-bot for Borislav Petkov @ 2017-09-07 10:34 UTC (permalink / raw) To: linux-tip-commits Cc: tglx, hpa, bp, linux-kernel, boris.ostrovsky, brijesh.singh, peterz, mingo, Thomas.Lendacky, torvalds Commit-ID: 21d9bb4a05bac50fb4f850517af4030baecd00f6 Gitweb: http://git.kernel.org/tip/21d9bb4a05bac50fb4f850517af4030baecd00f6 Author: Borislav Petkov <bp@suse.de> AuthorDate: Thu, 7 Sep 2017 11:38:37 +0200 Committer: Ingo Molnar <mingo@kernel.org> CommitDate: Thu, 7 Sep 2017 11:53:11 +0200 x86/mm: Make the SME mask a u64 The SME encryption mask is for masking 64-bit pagetable entries. It being an unsigned long works fine on X86_64 but on 32-bit builds in truncates bits leading to Xen guests crashing very early. And regardless, the whole SME mask handling shouldnt've leaked into 32-bit because SME is X86_64-only feature. So, first make the mask u64. And then, add trivial 32-bit versions of the __sme_* macros so that nothing happens there. Reported-and-tested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Tested-by: Brijesh Singh <brijesh.singh@amd.com> Signed-off-by: Borislav Petkov <bp@suse.de> Acked-by: Tom Lendacky <Thomas.Lendacky@amd.com> Acked-by: Thomas Gleixner <tglx@linutronix.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas <Thomas.Lendacky@amd.com> Fixes: 21729f81ce8a ("x86/mm: Provide general kernel support for memory encryption") Link: http://lkml.kernel.org/r/20170907093837.76zojtkgebwtqc74@pd.tnic Signed-off-by: Ingo Molnar <mingo@kernel.org> --- arch/x86/include/asm/mem_encrypt.h | 4 ++-- arch/x86/mm/mem_encrypt.c | 2 +- include/linux/mem_encrypt.h | 13 +++++++++---- 3 files changed, 12 insertions(+), 7 deletions(-) diff --git a/arch/x86/include/asm/mem_encrypt.h b/arch/x86/include/asm/mem_encrypt.h index 8e618fc..6a77c63 100644 --- a/arch/x86/include/asm/mem_encrypt.h +++ b/arch/x86/include/asm/mem_encrypt.h @@ -21,7 +21,7 @@ #ifdef CONFIG_AMD_MEM_ENCRYPT -extern unsigned long sme_me_mask; +extern u64 sme_me_mask; void sme_encrypt_execute(unsigned long encrypted_kernel_vaddr, unsigned long decrypted_kernel_vaddr, @@ -49,7 +49,7 @@ void swiotlb_set_mem_attributes(void *vaddr, unsigned long size); #else /* !CONFIG_AMD_MEM_ENCRYPT */ -#define sme_me_mask 0UL +#define sme_me_mask 0ULL static inline void __init sme_early_encrypt(resource_size_t paddr, unsigned long size) { } diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c index 0fbd092..3fcc8e0 100644 --- a/arch/x86/mm/mem_encrypt.c +++ b/arch/x86/mm/mem_encrypt.c @@ -37,7 +37,7 @@ static char sme_cmdline_off[] __initdata = "off"; * reside in the .data section so as not to be zeroed out when the .bss * section is later cleared. */ -unsigned long sme_me_mask __section(.data) = 0; +u64 sme_me_mask __section(.data) = 0; EXPORT_SYMBOL_GPL(sme_me_mask); /* Buffer used for early in-place encryption by BSP, no locking needed */ diff --git a/include/linux/mem_encrypt.h b/include/linux/mem_encrypt.h index 1255f09..265a9cd 100644 --- a/include/linux/mem_encrypt.h +++ b/include/linux/mem_encrypt.h @@ -21,7 +21,7 @@ #else /* !CONFIG_ARCH_HAS_MEM_ENCRYPT */ -#define sme_me_mask 0UL +#define sme_me_mask 0ULL #endif /* CONFIG_ARCH_HAS_MEM_ENCRYPT */ @@ -30,18 +30,23 @@ static inline bool sme_active(void) return !!sme_me_mask; } -static inline unsigned long sme_get_me_mask(void) +static inline u64 sme_get_me_mask(void) { return sme_me_mask; } +#ifdef CONFIG_AMD_MEM_ENCRYPT /* * The __sme_set() and __sme_clr() macros are useful for adding or removing * the encryption mask from a value (e.g. when dealing with pagetable * entries). */ -#define __sme_set(x) ((unsigned long)(x) | sme_me_mask) -#define __sme_clr(x) ((unsigned long)(x) & ~sme_me_mask) +#define __sme_set(x) ((x) | sme_me_mask) +#define __sme_clr(x) ((x) & ~sme_me_mask) +#else +#define __sme_set(x) (x) +#define __sme_clr(x) (x) +#endif #endif /* __ASSEMBLY__ */ ^ permalink raw reply related [flat|nested] 13+ messages in thread
* Re: SME/32-bit regression 2017-09-06 9:26 ` Borislav Petkov 2017-09-06 9:45 ` Borislav Petkov @ 2017-09-06 13:54 ` Boris Ostrovsky 2017-09-06 13:57 ` Thomas Gleixner 1 sibling, 1 reply; 13+ messages in thread From: Boris Ostrovsky @ 2017-09-06 13:54 UTC (permalink / raw) To: Borislav Petkov Cc: thomas.lendacky, X86 ML, linux-kernel, Ingo Molnar, H. Peter Anvin, Thomas Gleixner On 09/06/2017 05:26 AM, Borislav Petkov wrote: > On Tue, Sep 05, 2017 at 11:45:07PM -0400, Boris Ostrovsky wrote: >> It appears there is a regression for 32-bit kernels due to SME changes. >> >> I bisected my particular problem > It being? Doesn't boot, splats? Xen guest crashes very early, before a splat can can be generated. > >> (Xen PV guest) to >> 21729f81ce8ae76a6995681d40e16f7ce8075db4 but I also saw pmd_clear_bad() >> errors on baremetal. This seems to be caused by sme_me_mask being an >> unsigned long as opposed to phys_addr_t (the actual problem is that >> __PHYSICAL_MASK is truncated). When I declare it as u64 and drop unsigned >> long cast in __sme_set()/__sme_clr() the problem goes way. (This presumably >> won't work for non-PAE which I haven't tried). > Right, so I think we should do this because those macros should not have > any effect on !CONFIG_AMD_MEM_ENCRYPT setups. This won't help though if kernel is built with SME support. -boris > > --- > diff --git a/include/linux/mem_encrypt.h b/include/linux/mem_encrypt.h > index 1255f09f5e42..823eec6ba951 100644 > --- a/include/linux/mem_encrypt.h > +++ b/include/linux/mem_encrypt.h > @@ -35,6 +35,7 @@ static inline unsigned long sme_get_me_mask(void) > return sme_me_mask; > } > > +#ifdef CONFIG_AMD_MEM_ENCRYPT > /* > * The __sme_set() and __sme_clr() macros are useful for adding or removing > * the encryption mask from a value (e.g. when dealing with pagetable > @@ -42,6 +43,10 @@ static inline unsigned long sme_get_me_mask(void) > */ > #define __sme_set(x) ((unsigned long)(x) | sme_me_mask) > #define __sme_clr(x) ((unsigned long)(x) & ~sme_me_mask) > +#else > +#define __sme_set(x) (x) > +#define __sme_clr(x) (x) > +#endif > > #endif /* __ASSEMBLY__ */ > > > > ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: SME/32-bit regression 2017-09-06 13:54 ` SME/32-bit regression Boris Ostrovsky @ 2017-09-06 13:57 ` Thomas Gleixner 2017-09-06 14:03 ` Boris Ostrovsky 0 siblings, 1 reply; 13+ messages in thread From: Thomas Gleixner @ 2017-09-06 13:57 UTC (permalink / raw) To: Boris Ostrovsky Cc: Borislav Petkov, thomas.lendacky, X86 ML, linux-kernel, Ingo Molnar, H. Peter Anvin On Wed, 6 Sep 2017, Boris Ostrovsky wrote: > On 09/06/2017 05:26 AM, Borislav Petkov wrote: > > On Tue, Sep 05, 2017 at 11:45:07PM -0400, Boris Ostrovsky wrote: > >> It appears there is a regression for 32-bit kernels due to SME changes. > >> > >> I bisected my particular problem > > It being? Doesn't boot, splats? > > Xen guest crashes very early, before a splat can can be generated. > > > > >> (Xen PV guest) to > >> 21729f81ce8ae76a6995681d40e16f7ce8075db4 but I also saw pmd_clear_bad() > >> errors on baremetal. This seems to be caused by sme_me_mask being an > >> unsigned long as opposed to phys_addr_t (the actual problem is that > >> __PHYSICAL_MASK is truncated). When I declare it as u64 and drop unsigned > >> long cast in __sme_set()/__sme_clr() the problem goes way. (This presumably > >> won't work for non-PAE which I haven't tried). > > Right, so I think we should do this because those macros should not have > > any effect on !CONFIG_AMD_MEM_ENCRYPT setups. > > This won't help though if kernel is built with SME support. Which is not the case for 32bit. SME depends on 64bit ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: SME/32-bit regression 2017-09-06 13:57 ` Thomas Gleixner @ 2017-09-06 14:03 ` Boris Ostrovsky 0 siblings, 0 replies; 13+ messages in thread From: Boris Ostrovsky @ 2017-09-06 14:03 UTC (permalink / raw) To: Thomas Gleixner Cc: Borislav Petkov, thomas.lendacky, X86 ML, linux-kernel, Ingo Molnar, H. Peter Anvin On 09/06/2017 09:57 AM, Thomas Gleixner wrote: > On Wed, 6 Sep 2017, Boris Ostrovsky wrote: >> On 09/06/2017 05:26 AM, Borislav Petkov wrote: >>> On Tue, Sep 05, 2017 at 11:45:07PM -0400, Boris Ostrovsky wrote: >>>> It appears there is a regression for 32-bit kernels due to SME changes. >>>> >>>> I bisected my particular problem >>> It being? Doesn't boot, splats? >> Xen guest crashes very early, before a splat can can be generated. >> >>>> (Xen PV guest) to >>>> 21729f81ce8ae76a6995681d40e16f7ce8075db4 but I also saw pmd_clear_bad() >>>> errors on baremetal. This seems to be caused by sme_me_mask being an >>>> unsigned long as opposed to phys_addr_t (the actual problem is that >>>> __PHYSICAL_MASK is truncated). When I declare it as u64 and drop unsigned >>>> long cast in __sme_set()/__sme_clr() the problem goes way. (This presumably >>>> won't work for non-PAE which I haven't tried). >>> Right, so I think we should do this because those macros should not have >>> any effect on !CONFIG_AMD_MEM_ENCRYPT setups. >> This won't help though if kernel is built with SME support. > Which is not the case for 32bit. SME depends on 64bit Oh, OK, I didn't realize that. -boris ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2017-09-07 10:38 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-09-06 3:45 SME/32-bit regression Boris Ostrovsky
2017-09-06 9:26 ` Borislav Petkov
2017-09-06 9:45 ` Borislav Petkov
[not found] ` <CY4PR12MB11415936E980489690575E65EC970@CY4PR12MB1141.namprd12.prod.outlook.com>
2017-09-06 16:44 ` Borislav Petkov
2017-09-06 18:06 ` Brijesh Singh
2017-09-06 18:19 ` Borislav Petkov
2017-09-06 21:03 ` Boris Ostrovsky
2017-09-07 0:26 ` Brijesh Singh
2017-09-07 9:38 ` [PATCH] x86/mm: Make the SME mask a u64 Borislav Petkov
2017-09-07 10:34 ` [tip:x86/urgent] " tip-bot for Borislav Petkov
2017-09-06 13:54 ` SME/32-bit regression Boris Ostrovsky
2017-09-06 13:57 ` Thomas Gleixner
2017-09-06 14:03 ` Boris Ostrovsky
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).