Messages in this thread Patch in this message | | | Date | Wed, 6 Sep 2017 11:26:18 +0200 | From | Borislav Petkov <> | Subject | Re: SME/32-bit regression |
| |
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.
| |