public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: tip-bot for Tom Lendacky <tipbot@zytor.com>
To: linux-tip-commits@vger.kernel.org
Cc: hpa@zytor.com, labbott@redhat.com, matt@codeblueprint.co.uk,
	bp@suse.de, mingo@kernel.org, kirill.shutemov@linux.intel.com,
	thomas.lendacky@amd.com, brijesh.singh@amd.com,
	tglx@linutronix.de, linux-kernel@vger.kernel.org, bp@alien8.de,
	luto@kernel.org
Subject: [tip:x86/asm] x86/mm: Use encrypted access of boot related data with SEV
Date: Tue, 7 Nov 2017 06:44:29 -0800	[thread overview]
Message-ID: <tip-072f58c6ce29cf6cf429480fcd1b1e87d1d5ed18@git.kernel.org> (raw)
In-Reply-To: <20171020143059.3291-6-brijesh.singh@amd.com>

Commit-ID:  072f58c6ce29cf6cf429480fcd1b1e87d1d5ed18
Gitweb:     https://git.kernel.org/tip/072f58c6ce29cf6cf429480fcd1b1e87d1d5ed18
Author:     Tom Lendacky <thomas.lendacky@amd.com>
AuthorDate: Fri, 20 Oct 2017 09:30:47 -0500
Committer:  Thomas Gleixner <tglx@linutronix.de>
CommitDate: Tue, 7 Nov 2017 15:35:56 +0100

x86/mm: Use encrypted access of boot related data with SEV

When Secure Encrypted Virtualization (SEV) is active, boot data (such as
EFI related data, setup data) is encrypted and needs to be accessed as
such when mapped. Update the architecture override in early_memremap to
keep the encryption attribute when mapping this data.

Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Borislav Petkov <bp@suse.de>
Tested-by: Borislav Petkov <bp@suse.de>
Cc: Laura Abbott <labbott@redhat.com>
Cc: kvm@vger.kernel.org
Cc: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Link: https://lkml.kernel.org/r/20171020143059.3291-6-brijesh.singh@amd.com

---
 arch/x86/mm/ioremap.c | 44 ++++++++++++++++++++++++++++++--------------
 1 file changed, 30 insertions(+), 14 deletions(-)

diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
index 34f0e18..52cc0f4 100644
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -422,6 +422,9 @@ void unxlate_dev_mem_ptr(phys_addr_t phys, void *addr)
  * areas should be mapped decrypted. And since the encryption key can
  * change across reboots, persistent memory should also be mapped
  * decrypted.
+ *
+ * If SEV is active, that implies that BIOS/UEFI also ran encrypted so
+ * only persistent memory should be mapped decrypted.
  */
 static bool memremap_should_map_decrypted(resource_size_t phys_addr,
 					  unsigned long size)
@@ -458,6 +461,11 @@ static bool memremap_should_map_decrypted(resource_size_t phys_addr,
 	case E820_TYPE_ACPI:
 	case E820_TYPE_NVS:
 	case E820_TYPE_UNUSABLE:
+		/* For SEV, these areas are encrypted */
+		if (sev_active())
+			break;
+		/* Fallthrough */
+
 	case E820_TYPE_PRAM:
 		return true;
 	default:
@@ -581,7 +589,7 @@ static bool __init early_memremap_is_setup_data(resource_size_t phys_addr,
 bool arch_memremap_can_ram_remap(resource_size_t phys_addr, unsigned long size,
 				 unsigned long flags)
 {
-	if (!sme_active())
+	if (!mem_encrypt_active())
 		return true;
 
 	if (flags & MEMREMAP_ENC)
@@ -590,12 +598,13 @@ bool arch_memremap_can_ram_remap(resource_size_t phys_addr, unsigned long size,
 	if (flags & MEMREMAP_DEC)
 		return false;
 
-	if (memremap_is_setup_data(phys_addr, size) ||
-	    memremap_is_efi_data(phys_addr, size) ||
-	    memremap_should_map_decrypted(phys_addr, size))
-		return false;
+	if (sme_active()) {
+		if (memremap_is_setup_data(phys_addr, size) ||
+		    memremap_is_efi_data(phys_addr, size))
+			return false;
+	}
 
-	return true;
+	return !memremap_should_map_decrypted(phys_addr, size);
 }
 
 /*
@@ -608,17 +617,24 @@ pgprot_t __init early_memremap_pgprot_adjust(resource_size_t phys_addr,
 					     unsigned long size,
 					     pgprot_t prot)
 {
-	if (!sme_active())
+	bool encrypted_prot;
+
+	if (!mem_encrypt_active())
 		return prot;
 
-	if (early_memremap_is_setup_data(phys_addr, size) ||
-	    memremap_is_efi_data(phys_addr, size) ||
-	    memremap_should_map_decrypted(phys_addr, size))
-		prot = pgprot_decrypted(prot);
-	else
-		prot = pgprot_encrypted(prot);
+	encrypted_prot = true;
+
+	if (sme_active()) {
+		if (early_memremap_is_setup_data(phys_addr, size) ||
+		    memremap_is_efi_data(phys_addr, size))
+			encrypted_prot = false;
+	}
+
+	if (encrypted_prot && memremap_should_map_decrypted(phys_addr, size))
+		encrypted_prot = false;
 
-	return prot;
+	return encrypted_prot ? pgprot_encrypted(prot)
+			      : pgprot_decrypted(prot);
 }
 
 bool phys_mem_access_encrypted(unsigned long phys_addr, unsigned long size)

  reply	other threads:[~2017-11-07 14:47 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-20 14:30 [Part1 PATCH v7 00/17] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
2017-10-20 14:30 ` [Part1 PATCH v7 01/17] Documentation/x86: Add AMD Secure Encrypted Virtualization (SEV) description Brijesh Singh
2017-11-07 14:42   ` [tip:x86/asm] " tip-bot for Brijesh Singh
2017-10-20 14:30 ` [Part1 PATCH v7 02/17] x86/mm: Add Secure Encrypted Virtualization (SEV) support Brijesh Singh
2017-11-07 14:43   ` [tip:x86/asm] " tip-bot for Tom Lendacky
2017-10-20 14:30 ` [Part1 PATCH v7 03/17] x86/mm: Don't attempt to encrypt initrd under SEV Brijesh Singh
2017-11-07 14:43   ` [tip:x86/asm] " tip-bot for Tom Lendacky
2017-10-20 14:30 ` [Part1 PATCH v7 04/17] x86/realmode: Don't decrypt trampoline area " Brijesh Singh
2017-11-07 14:44   ` [tip:x86/asm] " tip-bot for Tom Lendacky
2017-10-20 14:30 ` [Part1 PATCH v7 05/17] x86/mm: Use encrypted access of boot related data with SEV Brijesh Singh
2017-11-07 14:44   ` tip-bot for Tom Lendacky [this message]
2017-10-20 14:30 ` [Part1 PATCH v7 06/17] x86/mm: Include SEV for encryption memory attribute changes Brijesh Singh
2017-11-07 14:44   ` [tip:x86/asm] " tip-bot for Tom Lendacky
2017-10-20 14:30 ` [Part1 PATCH v7 07/17] x86/efi: Access EFI data as encrypted when SEV is active Brijesh Singh
2017-11-07 14:45   ` [tip:x86/asm] " tip-bot for Tom Lendacky
2017-10-20 14:30 ` [Part1 PATCH v7 08/17] resource: Consolidate resource walking code Brijesh Singh
2017-11-07 14:45   ` [tip:x86/asm] " tip-bot for Tom Lendacky
2017-10-20 14:30 ` [Part1 PATCH v7 09/17] resource: Provide resource struct in resource walk callback Brijesh Singh
2017-11-07 14:46   ` [tip:x86/asm] " tip-bot for Tom Lendacky
2017-10-20 14:30 ` [Part1 PATCH v7 10/17] x86/mm, resource: Use PAGE_KERNEL protection for ioremap of memory pages Brijesh Singh
2017-11-07 14:46   ` [tip:x86/asm] " tip-bot for Tom Lendacky
2017-10-20 14:30 ` [Part1 PATCH v7 11/17] x86/mm: Add DMA support for SEV memory encryption Brijesh Singh
2017-11-07 14:46   ` [tip:x86/asm] " tip-bot for Tom Lendacky
2017-10-20 14:30 ` [Part1 PATCH v7 12/17] x86/boot: Add early boot support when running with SEV active Brijesh Singh
2017-11-07 14:47   ` [tip:x86/asm] " tip-bot for Tom Lendacky
2017-10-20 14:30 ` [Part1 PATCH v7 13/17] x86/io: Unroll string I/O when SEV is active Brijesh Singh
2017-10-20 18:39   ` Alan Cox
2017-10-21 11:26     ` Brijesh Singh
2017-11-07 14:47   ` [tip:x86/asm] " tip-bot for Tom Lendacky
2017-10-20 14:30 ` [Part1 PATCH v7 14/17] x86: Add support for changing memory encryption attribute in early boot Brijesh Singh
2017-11-07 14:48   ` [tip:x86/asm] " tip-bot for Brijesh Singh
2017-10-20 14:30 ` [Part1 PATCH v7 15/17] percpu: Introduce DEFINE_PER_CPU_DECRYPTED Brijesh Singh
2017-11-07 14:48   ` [tip:x86/asm] " tip-bot for Brijesh Singh
2017-10-20 14:30 ` [Part1 PATCH v7 16/17] X86/KVM: Decrypt shared per-cpu variables when SEV is active Brijesh Singh
2017-11-07 14:49   ` [tip:x86/asm] " tip-bot for Brijesh Singh
2017-10-20 14:30 ` [Part1 PATCH v7 17/17] X86/KVM: Clear encryption attribute " Brijesh Singh
2017-11-07 14:49   ` [tip:x86/asm] " tip-bot for Brijesh Singh
2017-11-15 23:57 ` [Part1 PATCH v7 00/17] x86: Secure Encrypted Virtualization (AMD) Steve Rutherford
2017-11-16 10:02   ` Borislav Petkov
2017-11-16 14:41     ` Tom Lendacky
2017-11-21 23:18       ` Steve Rutherford

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=tip-072f58c6ce29cf6cf429480fcd1b1e87d1d5ed18@git.kernel.org \
    --to=tipbot@zytor.com \
    --cc=bp@alien8.de \
    --cc=bp@suse.de \
    --cc=brijesh.singh@amd.com \
    --cc=hpa@zytor.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=labbott@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tip-commits@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=matt@codeblueprint.co.uk \
    --cc=mingo@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=thomas.lendacky@amd.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox