From: <gregkh@linuxfoundation.org>
To: 20180927123845.32052-1-kasong@redhat.com,
alexander.levin@microsoft.com, bhe@redhat.com, bp@suse.de,
brijesh.singh@amd.com, dyoung@redhat.com, ghook@redhat.com,
gregkh@linuxfoundation.org, hpa@zytor.com, kasong@redhat.com,
kexec@lists.infradead.org, mingo@redhat.com, tglx@linutronix.de,
thomas.lendacky@amd.com
Cc: stable-commits@vger.kernel.org
Subject: Patch "x86/boot: Fix kexec booting failure in the SEV bit detection code" has been added to the 4.18-stable tree
Date: Thu, 18 Oct 2018 11:50:52 +0200 [thread overview]
Message-ID: <153985625228102@kroah.com> (raw)
This is a note to let you know that I've just added the patch titled
x86/boot: Fix kexec booting failure in the SEV bit detection code
to the 4.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
x86-boot-fix-kexec-booting-failure-in-the-sev-bit-detection-code.patch
and it can be found in the queue-4.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
From foo@baz Thu Oct 18 11:08:35 CEST 2018
From: Kairui Song <kasong@redhat.com>
Date: Thu, 27 Sep 2018 20:38:45 +0800
Subject: x86/boot: Fix kexec booting failure in the SEV bit detection code
From: Kairui Song <kasong@redhat.com>
[ Upstream commit bdec8d7fa55e6f5314ed72e5a0b435d90ff90548 ]
Commit
1958b5fc4010 ("x86/boot: Add early boot support when running with SEV active")
can occasionally cause system resets when kexec-ing a second kernel even
if SEV is not active.
That's because get_sev_encryption_bit() uses 32-bit rIP-relative
addressing to read the value of enc_bit - a variable which caches a
previously detected encryption bit position - but kexec may allocate
the early boot code to a higher location, beyond the 32-bit addressing
limit.
In this case, garbage will be read and get_sev_encryption_bit() will
return the wrong value, leading to accessing memory with the wrong
encryption setting.
Therefore, remove enc_bit, and thus get rid of the need to do 32-bit
rIP-relative addressing in the first place.
[ bp: massage commit message heavily. ]
Fixes: 1958b5fc4010 ("x86/boot: Add early boot support when running with SEV active")
Suggested-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Kairui Song <kasong@redhat.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
Cc: linux-kernel@vger.kernel.org
Cc: tglx@linutronix.de
Cc: mingo@redhat.com
Cc: hpa@zytor.com
Cc: brijesh.singh@amd.com
Cc: kexec@lists.infradead.org
Cc: dyoung@redhat.com
Cc: bhe@redhat.com
Cc: ghook@redhat.com
Link: https://lkml.kernel.org/r/20180927123845.32052-1-kasong@redhat.com
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/boot/compressed/mem_encrypt.S | 19 -------------------
1 file changed, 19 deletions(-)
--- a/arch/x86/boot/compressed/mem_encrypt.S
+++ b/arch/x86/boot/compressed/mem_encrypt.S
@@ -25,20 +25,6 @@ ENTRY(get_sev_encryption_bit)
push %ebx
push %ecx
push %edx
- push %edi
-
- /*
- * RIP-relative addressing is needed to access the encryption bit
- * variable. Since we are running in 32-bit mode we need this call/pop
- * sequence to get the proper relative addressing.
- */
- call 1f
-1: popl %edi
- subl $1b, %edi
-
- movl enc_bit(%edi), %eax
- cmpl $0, %eax
- jge .Lsev_exit
/* Check if running under a hypervisor */
movl $1, %eax
@@ -69,15 +55,12 @@ ENTRY(get_sev_encryption_bit)
movl %ebx, %eax
andl $0x3f, %eax /* Return the encryption bit location */
- movl %eax, enc_bit(%edi)
jmp .Lsev_exit
.Lno_sev:
xor %eax, %eax
- movl %eax, enc_bit(%edi)
.Lsev_exit:
- pop %edi
pop %edx
pop %ecx
pop %ebx
@@ -113,8 +96,6 @@ ENTRY(set_sev_encryption_mask)
ENDPROC(set_sev_encryption_mask)
.data
-enc_bit:
- .int 0xffffffff
#ifdef CONFIG_AMD_MEM_ENCRYPT
.balign 8
Patches currently in stable-queue which might be from kasong@redhat.com are
queue-4.18/x86-boot-fix-kexec-booting-failure-in-the-sev-bit-detection-code.patch
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
reply other threads:[~2018-10-18 9:54 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=153985625228102@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=20180927123845.32052-1-kasong@redhat.com \
--cc=alexander.levin@microsoft.com \
--cc=bhe@redhat.com \
--cc=bp@suse.de \
--cc=brijesh.singh@amd.com \
--cc=dyoung@redhat.com \
--cc=ghook@redhat.com \
--cc=hpa@zytor.com \
--cc=kasong@redhat.com \
--cc=kexec@lists.infradead.org \
--cc=mingo@redhat.com \
--cc=stable-commits@vger.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 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.