All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: Tom Lendacky <thomas.lendacky@amd.com>
Cc: x86@kernel.org, linux-kernel@vger.kernel.org,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Andy Lutomirski <luto@kernel.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Dave Young <dyoung@redhat.com>,
	Brijesh Singh <brijesh.singh@amd.com>
Subject: Re: [PATCH v1 2/2] acpi, x86: Remove encryption mask from ACPI page protection type
Date: Thu, 27 Jul 2017 09:39:04 +0200	[thread overview]
Message-ID: <20170727073904.iay5jclhhjnqhyib@gmail.com> (raw)
In-Reply-To: <45cc8e44980cbc1372c63420ebafc8c8466e958f.1501092102.git.thomas.lendacky@amd.com>


* Tom Lendacky <thomas.lendacky@amd.com> 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@amd.com>
> ---
>  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;

'in in memory'?

Also, this seems a bit ad-hoc to me. What are the rules for what is encrypted and 
what is not?

I presume the main rule is that everything that was written before the kernel 
activates SME, and which the kernel will read later on, is unencrypted - 
everything else is encrypted. Is that correct?

How about things like kexec creating a separate mptable for the kexec kernel - 
would that code have to create unencrypted data? See 
e820__memblock_alloc_reserved() and related code.

Thanks,

	Ingo

  reply	other threads:[~2017-07-27  7:39 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-26 18:04 [PATCH v1 0/2] x86: Secure Memory Encryption (SME) fixes 2017-07-26 Tom Lendacky
2017-07-26 18:04 ` Tom Lendacky
2017-07-26 18:04 ` [PATCH v1 1/2] x86/mm, kexec: Fix memory corruption with SME on successive kexecs Tom Lendacky
2017-07-26 18:04   ` Tom Lendacky
2017-07-27  7:17   ` Ingo Molnar
2017-07-27  7:17     ` Ingo Molnar
2017-07-27 14:15     ` Tom Lendacky
2017-07-27 14:15       ` Tom Lendacky
2017-07-27 17:34       ` Linus Torvalds
2017-07-27 17:34         ` Linus Torvalds
2017-07-27 18:47         ` Tom Lendacky
2017-07-27 18:47           ` Tom Lendacky
2017-07-26 18:04 ` [PATCH v1 2/2] acpi, x86: Remove encryption mask from ACPI page protection type Tom Lendacky
2017-07-27  7:39   ` Ingo Molnar [this message]
2017-07-27 14:53     ` Tom Lendacky
2017-07-27 14:41   ` Borislav Petkov
2017-07-27 14:57     ` Tom Lendacky
2017-07-28  6:28       ` Ingo Molnar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170727073904.iay5jclhhjnqhyib@gmail.com \
    --to=mingo@kernel.org \
    --cc=bp@alien8.de \
    --cc=brijesh.singh@amd.com \
    --cc=dyoung@redhat.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=thomas.lendacky@amd.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.