From: Tom Lendacky <thomas.lendacky@amd.com>
To: Ard Biesheuvel <ardb@kernel.org>, linux-efi@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, Evgeniy Baskov <baskov@ispras.ru>,
Borislav Petkov <bp@alien8.de>, Andy Lutomirski <luto@kernel.org>,
Dave Hansen <dave.hansen@linux.intel.com>,
Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Thomas Gleixner <tglx@linutronix.de>,
Alexey Khoroshilov <khoroshilov@ispras.ru>,
Peter Jones <pjones@redhat.com>,
Gerd Hoffmann <kraxel@redhat.com>, Dave Young <dyoung@redhat.com>,
Mario Limonciello <mario.limonciello@amd.com>,
Kees Cook <keescook@chromium.org>,
"Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Joerg Roedel <jroedel@suse.de>
Subject: Re: [PATCH v4 20/21] x86/efistub: Perform SNP feature test while running in the firmware
Date: Fri, 2 Jun 2023 15:39:51 -0500 [thread overview]
Message-ID: <849a65c8-a320-a8a8-8784-0ee3737eee9e@amd.com> (raw)
In-Reply-To: <bfe5bbac-37e2-6728-606a-c652bafad6b6@amd.com>
On 6/2/23 15:38, Tom Lendacky wrote:
> On 6/2/23 05:13, Ard Biesheuvel wrote:
>> Before refactoring the EFI stub boot flow to avoid the legacy bare metal
>> decompressor, duplicate the SNP feature check in the EFI stub before
>> handing over to the kernel proper.
>>
>> The SNP feature check can be performed while running under the EFI boot
>> services, which means we can fail gracefully and return an error to the
>> bootloader if the loaded kernel does not implement support for all the
>> features that the hypervisor enabled.
>>
>> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
>> ---
>> arch/x86/boot/compressed/sev.c | 74 ++++++++++++--------
>> arch/x86/include/asm/sev.h | 4 ++
>> drivers/firmware/efi/libstub/x86-stub.c | 17 +++++
>> 3 files changed, 67 insertions(+), 28 deletions(-)
>>
>> diff --git a/arch/x86/boot/compressed/sev.c
>> b/arch/x86/boot/compressed/sev.c
>> index 014b89c890887b9a..be021e24f1ece421 100644
>> --- a/arch/x86/boot/compressed/sev.c
>> +++ b/arch/x86/boot/compressed/sev.c
>
>
>> +void sev_enable(struct boot_params *bp)
>> +{
>> + unsigned int eax, ebx, ecx, edx;
>> bool snp;
>> /*
>> @@ -358,37 +391,14 @@ void sev_enable(struct boot_params *bp)
>> */
>> snp = snp_init(bp);
>> - /* Check for the SME/SEV support leaf */
>> - eax = 0x80000000;
>> - ecx = 0;
>> - native_cpuid(&eax, &ebx, &ecx, &edx);
>> - if (eax < 0x8000001f)
>> - return;
>> -
>> - /*
>> - * Check for the SME/SEV feature:
>> - * CPUID Fn8000_001F[EAX]
>> - * - Bit 0 - Secure Memory Encryption support
>> - * - Bit 1 - Secure Encrypted Virtualization support
>> - * CPUID Fn8000_001F[EBX]
>> - * - Bits 5:0 - Pagetable bit position used to indicate encryption
>> - */
>> - eax = 0x8000001f;
>> - ecx = 0;
>> - native_cpuid(&eax, &ebx, &ecx, &edx);
>> - /* Check whether SEV is supported */
>> - if (!(eax & BIT(1))) {
>> + /* Set the SME mask if this is an SEV guest. */
>> + sev_status = sev_get_status();
>> + if (!(sev_status & MSR_AMD64_SEV_ENABLED)) {
>> if (snp)
>> error("SEV-SNP support indicated by CC blob, but not
>> CPUID.");
>> return;
>> }
>> - /* Set the SME mask if this is an SEV guest. */
>> - boot_rdmsr(MSR_AMD64_SEV, &m);
>> - sev_status = m.q;
>> - if (!(sev_status & MSR_AMD64_SEV_ENABLED))
>> - return;
>> -
>> /* Negotiate the GHCB protocol version. */
>> if (sev_status & MSR_AMD64_SEV_ES_ENABLED) {
>> if (!sev_es_negotiate_protocol())
>> @@ -409,6 +419,14 @@ void sev_enable(struct boot_params *bp)
>> if (snp && !(sev_status & MSR_AMD64_SEV_SNP_ENABLED))
>> error("SEV-SNP supported indicated by CC blob, but not SEV
>> status MSR.");
>> + /*
>> + * Check for the SME/SEV feature:
>> + * CPUID Fn8000_001F[EBX]
>> + * - Bits 5:0 - Pagetable bit position used to indicate encryption
>> + */
>> + eax = 0x8000001f;
>> + ecx = 0;
>> + native_cpuid(&eax, &ebx, &ecx, &edx);
>
> This causes SEV-ES / SEV-SNP to crash.
>
> This goes back to a previous comment where calling either
> sev_es_negotiate_protocol() or get_hv_features() blows away the GHCB value
> in the GHCB MSR and as soon as the CPUID instruction is executed the boot
> blows up.
>
> Even if we move this up to be done earlier, we can complete this function
> successfully but then blow up further on.
>
> So you probably have to modify the routines in question to save and
> restore the GHCB MSR value.
I should clarify that it doesn't in fact cause a problem until the final
patch is applied and this path is taken.
Thanks,
Tom
>
> Thanks,
> Tom
>
>> sme_me_mask = BIT_ULL(ebx & 0x3f);
>> }
next prev parent reply other threads:[~2023-06-02 20:40 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-02 10:12 [PATCH v4 00/21] efi/x86: Avoid bare metal decompressor during EFI boot Ard Biesheuvel
2023-06-02 10:12 ` [PATCH v4 01/21] x86/efistub: Branch straight to kernel entry point from C code Ard Biesheuvel
2023-06-02 10:12 ` [PATCH v4 02/21] x86/efistub: Simplify and clean up handover entry code Ard Biesheuvel
2023-06-02 10:12 ` [PATCH v4 03/21] x86/decompressor: Avoid magic offsets for EFI handover entrypoint Ard Biesheuvel
2023-06-02 10:12 ` [PATCH v4 04/21] x86/efistub: Clear BSS in EFI handover protocol entrypoint Ard Biesheuvel
2023-06-02 10:12 ` [PATCH v4 05/21] x86/decompressor: Use proper sequence to take the address of the GOT Ard Biesheuvel
2023-06-02 10:12 ` [PATCH v4 06/21] x86/decompressor: Store boot_params pointer in callee save register Ard Biesheuvel
2023-06-02 10:12 ` [PATCH v4 07/21] x86/decompressor: Call trampoline as a normal function Ard Biesheuvel
2023-06-02 10:13 ` [PATCH v4 08/21] x86/decompressor: Use standard calling convention for trampoline Ard Biesheuvel
2023-06-02 10:13 ` [PATCH v4 09/21] x86/decompressor: Avoid the need for a stack in the 32-bit trampoline Ard Biesheuvel
2023-06-02 10:13 ` [PATCH v4 10/21] x86/decompressor: Call trampoline directly from C code Ard Biesheuvel
2023-06-02 10:13 ` [PATCH v4 11/21] x86/decompressor: Only call the trampoline when changing paging levels Ard Biesheuvel
2023-06-02 10:13 ` [PATCH v4 12/21] x86/decompressor: Merge trampoline cleanup with switching code Ard Biesheuvel
2023-06-02 10:13 ` [PATCH v4 13/21] x86/efistub: Perform 4/5 level paging switch from the stub Ard Biesheuvel
2023-06-02 10:13 ` [PATCH v4 14/21] x86/efistub: Prefer EFI memory attributes protocol over DXE services Ard Biesheuvel
2023-06-02 10:13 ` [PATCH v4 15/21] decompress: Use 8 byte alignment Ard Biesheuvel
2023-06-02 10:13 ` [PATCH v4 16/21] x86/decompressor: Move global symbol references to C code Ard Biesheuvel
2023-06-02 10:13 ` [PATCH v4 17/21] x86/decompressor: Factor out kernel decompression and relocation Ard Biesheuvel
2023-06-02 10:13 ` [PATCH v4 18/21] x86/head_64: Store boot_params pointer in callee-preserved register Ard Biesheuvel
2023-06-02 10:13 ` [PATCH v4 19/21] efi/libstub: Add limit argument to efi_random_alloc() Ard Biesheuvel
2023-06-02 10:13 ` [PATCH v4 20/21] x86/efistub: Perform SNP feature test while running in the firmware Ard Biesheuvel
2023-06-02 20:38 ` Tom Lendacky
2023-06-02 20:39 ` Tom Lendacky [this message]
2023-06-02 21:29 ` Ard Biesheuvel
2023-06-02 22:01 ` Tom Lendacky
2023-06-02 22:22 ` Ard Biesheuvel
2023-06-02 10:13 ` [PATCH v4 21/21] x86/efistub: Avoid legacy decompressor when doing EFI boot Ard Biesheuvel
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=849a65c8-a320-a8a8-8784-0ee3737eee9e@amd.com \
--to=thomas.lendacky@amd.com \
--cc=ardb@kernel.org \
--cc=baskov@ispras.ru \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=dyoung@redhat.com \
--cc=jroedel@suse.de \
--cc=keescook@chromium.org \
--cc=khoroshilov@ispras.ru \
--cc=kirill.shutemov@linux.intel.com \
--cc=kraxel@redhat.com \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mario.limonciello@amd.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=pjones@redhat.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox