mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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:38:37 -0500	[thread overview]
Message-ID: <bfe5bbac-37e2-6728-606a-c652bafad6b6@amd.com> (raw)
In-Reply-To: <20230602101313.3557775-21-ardb@kernel.org>

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.

Thanks,
Tom

>   	sme_me_mask = BIT_ULL(ebx & 0x3f);
>   }
>   

  reply	other threads:[~2023-06-02 20:38 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 [this message]
2023-06-02 20:39     ` Tom Lendacky
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=bfe5bbac-37e2-6728-606a-c652bafad6b6@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

all inboxes | Powered by JetHome®