On 4/24/2017 10:57 AM, Dave Hansen wrote:
On 04/24/2017 08:53 AM, Tom Lendacky wrote:
On 4/21/2017 4:52 PM, Dave Hansen wrote:
On 04/18/2017 02:17 PM, Tom Lendacky wrote:
@@ -55,7 +57,7 @@ static inline void copy_user_page(void *to, void
*from, unsigned long vaddr,
__phys_addr_symbol(__phys_reloc_hide((unsigned long)(x)))
#ifndef __va
-#define __va(x) ((void *)((unsigned long)(x)+PAGE_OFFSET))
+#define __va(x) ((void *)(__sme_clr(x) + PAGE_OFFSET))
#endif
It seems wrong to be modifying __va(). It currently takes a physical
address, and this modifies it to take a physical address plus the SME
bits.
This actually modifies it to be sure the encryption bit is not part of
the physical address.
If SME bits make it this far, we have a bug elsewhere. Right? Probably
best not to paper over it.
That all depends on the approach. Currently that's not the case for
the one situation that you mentioned with cr3. But if we do take the
approach that we should never feed physical addresses to __va() with
the encryption bit set then, yes, it would imply a bug elsewhere - which
is probably a good approach.
I'll work on that. I could even add a debug config option that would
issue a warning should __va() encounter the encryption bit if SME is
enabled or active.
Thanks,
Tom
