All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joerg Roedel <jroedel@suse.de>
To: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Ard Biesheuvel <ardb@kernel.org>,
	linux-efi@vger.kernel.org, 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>
Subject: Re: [PATCH v2 17/20] x86: efistub: Check SEV/SNP support while running in the firmware
Date: Mon, 22 May 2023 14:48:44 +0200	[thread overview]
Message-ID: <ZGtkrKhxqUiTlXY0@suse.de> (raw)
In-Reply-To: <b6192de1-26a4-a7a7-63bf-76c36f55a8ff@amd.com>

On Fri, May 19, 2023 at 09:04:46AM -0500, Tom Lendacky wrote:
> Deferring the checks is probably the safest thing to do, since that would
> match the way things are done today and known to work. I'm not sure what
> other things might pop up if we stay with this approach, for example, page
> state change calls using the GHCB MSR protocol that also don't save/restore
> the MSR value.
> 
> It is possible to audit these areas and stay with this approach, but I'm
> wondering if that wouldn't be better done as a separate patch series.
> 
> Adding @Joerg for any additional thoughts he might have around this area, too.

If I got it correctly the patch actually moves two things before
ExitBootServices:

	1) SEV features check

	2) SEV initialization

I think it makes a lot of sense to have 1) before ExitBootServices. It
allows to soft-fail in case the kernel does not support all required
SEV-SNP features and move on to a kernel which does. This check also only
needs the SEV_STATUS MSR and not any GHCB calls.

The problem is the GHCB protocol negotiation with the HV, but the GHCB
protocol is downward-compatible, so an older kernel can work with a
newer HV.

But 2) needs to stay after ExitBootServices, as it needs resources owned
by UEFI, e.g. the GHCB MSR and potentially the configured GHCB itself.
Fiddling around with the GHCB MSR while it is still owned by UEFI will
bite us in one or the other way (e.g. UEFI, before ExitBootServices, is
free to take IRQs with handlers that rely on the GHCB MSR content).

Regards,

	Joerg


  reply	other threads:[~2023-05-22 12:49 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-08  7:03 [PATCH v2 00/20] efi/x86: Avoid bare metal decompressor during EFI boot Ard Biesheuvel
2023-05-08  7:03 ` [PATCH v2 01/20] x86: decompressor: Use proper sequence to take the address of the GOT Ard Biesheuvel
2023-05-17 17:31   ` Borislav Petkov
2023-05-17 17:39     ` Ard Biesheuvel
2023-05-08  7:03 ` [PATCH v2 02/20] x86: decompressor: Store boot_params pointer in callee save register Ard Biesheuvel
2023-05-08  7:03 ` [PATCH v2 03/20] x86: decompressor: Call trampoline as a normal function Ard Biesheuvel
2023-05-15 13:59   ` Kirill A. Shutemov
2023-05-08  7:03 ` [PATCH v2 04/20] x86: decompressor: Use standard calling convention for trampoline Ard Biesheuvel
2023-05-15 14:00   ` Kirill A. Shutemov
2023-05-08  7:03 ` [PATCH v2 05/20] x86: decompressor: Avoid the need for a stack in the 32-bit trampoline Ard Biesheuvel
2023-05-15 14:03   ` Kirill A. Shutemov
2023-05-17 22:40   ` Tom Lendacky
2023-05-18 14:55     ` Ard Biesheuvel
2023-05-08  7:03 ` [PATCH v2 06/20] x86: decompressor: Call trampoline directly from C code Ard Biesheuvel
2023-05-15 14:05   ` Kirill A. Shutemov
2023-05-08  7:03 ` [PATCH v2 07/20] x86: decompressor: Only call the trampoline when changing paging levels Ard Biesheuvel
2023-05-15 14:07   ` Kirill A. Shutemov
2023-05-08  7:03 ` [PATCH v2 08/20] x86: decompressor: Merge trampoline cleanup with switching code Ard Biesheuvel
     [not found]   ` <20230515140955.d4adbstv6gtnshp2@box.shutemov.name>
2023-05-16 17:50     ` Ard Biesheuvel
2023-05-08  7:03 ` [PATCH v2 09/20] x86: efistub: Perform 4/5 level paging switch from the stub Ard Biesheuvel
2023-05-15 14:14   ` Kirill A. Shutemov
2023-05-16 17:53     ` Ard Biesheuvel
2023-05-08  7:03 ` [PATCH v2 10/20] x86: efistub: Prefer EFI memory attributes protocol over DXE services Ard Biesheuvel
2023-05-08  7:03 ` [PATCH v2 11/20] decompress: Use 8 byte alignment Ard Biesheuvel
2023-05-08  7:03 ` [PATCH v2 12/20] x86: decompressor: Move global symbol references to C code Ard Biesheuvel
2023-05-08  7:03 ` [PATCH v2 13/20] x86: decompressor: Factor out kernel decompression and relocation Ard Biesheuvel
2023-05-08  7:03 ` [PATCH v2 14/20] x86: head_64: Store boot_params pointer in callee-preserved register Ard Biesheuvel
2023-05-08  7:03 ` [PATCH v2 15/20] x86: head_64: Switch to kernel CS before enabling memory encryption Ard Biesheuvel
2023-05-17 18:54   ` Tom Lendacky
2023-05-08  7:03 ` [PATCH v2 16/20] efi: libstub: Add limit argument to efi_random_alloc() Ard Biesheuvel
2023-05-08  7:03 ` [PATCH v2 17/20] x86: efistub: Check SEV/SNP support while running in the firmware Ard Biesheuvel
2023-05-18 20:16   ` Tom Lendacky
2023-05-18 22:27     ` Ard Biesheuvel
2023-05-19 14:04       ` Tom Lendacky
2023-05-22 12:48         ` Joerg Roedel [this message]
2023-05-22 13:07           ` Ard Biesheuvel
2023-05-22 13:35             ` Joerg Roedel
2023-05-08  7:03 ` [PATCH v2 18/20] x86: efistub: Avoid legacy decompressor when doing EFI boot Ard Biesheuvel
2023-05-18 20:48   ` Tom Lendacky
2023-05-18 22:33     ` Ard Biesheuvel
2023-05-08  7:03 ` [PATCH v2 19/20] x86: efistub: Clear BSS in EFI handover protocol entrypoint Ard Biesheuvel
2023-05-08  7:03 ` [PATCH v2 20/20] x86: decompressor: Avoid magic offsets for EFI handover entrypoint 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=ZGtkrKhxqUiTlXY0@suse.de \
    --to=jroedel@suse.de \
    --cc=ardb@kernel.org \
    --cc=baskov@ispras.ru \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=dyoung@redhat.com \
    --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=thomas.lendacky@amd.com \
    --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 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.