Re: [PATCH v1 2/2] acpi, x86: Remove encryption mask from ACPI page protection type

From: Tom Lendacky
Date: Thu Jul 27 2017 - 10:57:58 EST


On 7/27/2017 9:41 AM, Borislav Petkov wrote:
On Wed, Jul 26, 2017 at 01:04:34PM -0500, Tom Lendacky wrote:
The function arch_apei_get_mem_attributes() is used to set the page
protection type for ACPI physical addresses. When SME is active, the
associated protection type needs to not have the encryption mask set
since the ACPI tables live in un-encrypted memory. Modify the
arch_apei_get_mem_attributes() function to remove the encryption mask
when SME is active by returning the PAGE_KERNEL_IO protection type.

Signed-off-by: Tom Lendacky <thomas.lendacky@xxxxxxx>
---
arch/x86/include/asm/acpi.h | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/acpi.h b/arch/x86/include/asm/acpi.h
index 562286f..89df39d 100644
--- a/arch/x86/include/asm/acpi.h
+++ b/arch/x86/include/asm/acpi.h
@@ -34,6 +34,7 @@
#ifdef CONFIG_ACPI_APEI
# include <asm/pgtable_types.h>
+# include <linux/mem_encrypt.h>
#endif
#ifdef CONFIG_ACPI
@@ -164,8 +165,12 @@ static inline pgprot_t arch_apei_get_mem_attribute(phys_addr_t addr)
* anything other than PAGE_KERNEL (some arm64 platforms
* require the equivalent of PAGE_KERNEL_NOCACHE), return that
* until we know differently.
+ *
+ * When SME is active, the ACPI information will not reside in
+ * in memory in an encrypted state so return a protection attribute
+ * that does not have the encryption bit set.
*/
- return PAGE_KERNEL;
+ return sme_active() ? PAGE_KERNEL_IO : PAGE_KERNEL;

Why isn't there a PAGE_KERNEL_NOENC define which you can simply return
instead of testing?

Sounds like something I should add to pgtable_types.h (which has a
#define for PAGE_KERNEL_EXEC_NOENC, but not PAGE_KERNEL_NOENC). I'll
create that #define.

As for the sme_active() check I was getting ahead of myself since
under SEV the encryption mask is needed. I'll change it to just
return PAGE_KERNEL_NOENC and then worry about the SEV change in
the SEV patches.

Thanks,
Tom