lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <tip-1a79c1b8a04153c4c387518967ce851f89e22733@git.kernel.org>
Date:   Thu, 20 Jun 2019 03:01:52 -0700
From:   tip-bot for Lianbo Jiang <tipbot@...or.com>
To:     linux-tip-commits@...r.kernel.org
Cc:     lijiang@...hat.com, mingo@...nel.org, tglx@...utronix.de,
        bp@...e.de, akpm@...ux-foundation.org, thomas.lendacky@....com,
        kirill.shutemov@...ux.intel.com, hpa@...or.com,
        linux-kernel@...r.kernel.org, x86@...nel.org,
        brijesh.singh@....com, mingo@...hat.com
Subject: [tip:x86/kdump] x86/kexec: Do not map kexec area as decrypted when
 SEV is active

Commit-ID:  1a79c1b8a04153c4c387518967ce851f89e22733
Gitweb:     https://git.kernel.org/tip/1a79c1b8a04153c4c387518967ce851f89e22733
Author:     Lianbo Jiang <lijiang@...hat.com>
AuthorDate: Tue, 30 Apr 2019 15:44:19 +0800
Committer:  Borislav Petkov <bp@...e.de>
CommitDate: Thu, 20 Jun 2019 10:06:46 +0200

x86/kexec: Do not map kexec area as decrypted when SEV is active

When a virtual machine panics, its memory needs to be dumped for
analysis. With memory encryption in the picture, special care must be
taken when loading a kexec/kdump kernel in a SEV guest.

A SEV guest starts and runs fully encrypted. In order to load a kexec
kernel and initrd, arch_kexec_post_{alloc,free}_pages() need to not map
areas as decrypted unconditionally but differentiate whether the kernel
is running as a SEV guest and if so, leave kexec area encrypted.

 [ bp: Reduce commit message to the relevant information pertaining to
   this commit only. ]

Co-developed-by: Brijesh Singh <brijesh.singh@....com>
Signed-off-by: Brijesh Singh <brijesh.singh@....com>
Signed-off-by: Lianbo Jiang <lijiang@...hat.com>
Signed-off-by: Borislav Petkov <bp@...e.de>
Cc: Andrew Morton <akpm@...ux-foundation.org>
Cc: bhe@...hat.com
Cc: Brijesh Singh <brijesh.singh@....com>
Cc: dyoung@...hat.com
Cc: "H. Peter Anvin" <hpa@...or.com>
Cc: Ingo Molnar <mingo@...hat.com>
Cc: kexec@...ts.infradead.org
Cc: "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>
Cc: Thomas Gleixner <tglx@...utronix.de>
Cc: Tom Lendacky <thomas.lendacky@....com>
Cc: x86-ml <x86@...nel.org>
Link: https://lkml.kernel.org/r/20190430074421.7852-2-lijiang@redhat.com
---
 arch/x86/kernel/machine_kexec_64.c | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/arch/x86/kernel/machine_kexec_64.c b/arch/x86/kernel/machine_kexec_64.c
index ceba408ea982..3b38449028e0 100644
--- a/arch/x86/kernel/machine_kexec_64.c
+++ b/arch/x86/kernel/machine_kexec_64.c
@@ -559,8 +559,20 @@ void arch_kexec_unprotect_crashkres(void)
 	kexec_mark_crashkres(false);
 }
 
+/*
+ * During a traditional boot under SME, SME will encrypt the kernel,
+ * so the SME kexec kernel also needs to be un-encrypted in order to
+ * replicate a normal SME boot.
+ *
+ * During a traditional boot under SEV, the kernel has already been
+ * loaded encrypted, so the SEV kexec kernel needs to be encrypted in
+ * order to replicate a normal SEV boot.
+ */
 int arch_kexec_post_alloc_pages(void *vaddr, unsigned int pages, gfp_t gfp)
 {
+	if (sev_active())
+		return 0;
+
 	/*
 	 * If SME is active we need to be sure that kexec pages are
 	 * not encrypted because when we boot to the new kernel the
@@ -571,6 +583,9 @@ int arch_kexec_post_alloc_pages(void *vaddr, unsigned int pages, gfp_t gfp)
 
 void arch_kexec_pre_free_pages(void *vaddr, unsigned int pages)
 {
+	if (sev_active())
+		return;
+
 	/*
 	 * If SME is active we need to reset the pages back to being
 	 * an encrypted mapping before freeing them.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ