On 2/19/24 11:06, Ard Biesheuvel wrote:
On Mon, 19 Feb 2024 at 18:00, Tom Lendacky <thomas.lendacky@xxxxxxx> wrote:
On 2/13/24 06:41, Ard Biesheuvel wrote:
From: Ard Biesheuvel <ardb@xxxxxxxxxx>
Parse the mem_encrypt= command line parameter from the EFI stub if
CONFIG_ARCH_HAS_MEM_ENCRYPT=y, so that it can be passed to the early
boot code by the arch code in the stub.
This avoids the need for the core kernel to do any string parsing very
early in the boot.
Signed-off-by: Ard Biesheuvel <ardb@xxxxxxxxxx>
---
drivers/firmware/efi/libstub/efi-stub-helper.c | 8 ++++++++
drivers/firmware/efi/libstub/efistub.h | 2 +-
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/firmware/efi/libstub/efi-stub-helper.c b/drivers/firmware/efi/libstub/efi-stub-helper.c
index bfa30625f5d0..3dc2f9aaf08d 100644
--- a/drivers/firmware/efi/libstub/efi-stub-helper.c
+++ b/drivers/firmware/efi/libstub/efi-stub-helper.c
@@ -24,6 +24,8 @@ static bool efi_noinitrd;
static bool efi_nosoftreserve;
static bool efi_disable_pci_dma = IS_ENABLED(CONFIG_EFI_DISABLE_PCI_DMA);
+int efi_mem_encrypt;
+
bool __pure __efi_soft_reserve_enabled(void)
{
return !efi_nosoftreserve;
@@ -75,6 +77,12 @@ efi_status_t efi_parse_options(char const *cmdline)
efi_noinitrd = true;
} else if (IS_ENABLED(CONFIG_X86_64) && !strcmp(param, "no5lvl")) {
efi_no5lvl = true;
+ } else if (IS_ENABLED(CONFIG_ARCH_HAS_MEM_ENCRYPT) &&
+ !strcmp(param, "mem_encrypt") && val) {
+ if (parse_option_str(val, "on"))
+ efi_mem_encrypt = 1;
+ else if (parse_option_str(val, "off"))
+ efi_mem_encrypt = -1;
With CONFIG_AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT having recently been
removed, I'm not sure what parsing for mem_encrypt=off does.
(Same thing in the next patch.)
We have to deal with both mem_encrypt=on and mem_encrypt=off occurring
on the command line. efi_parse_options() may be called more than once,
i.e., when there is a default command line baked into the image that
can be overridden at runtime. So if the baked in one has
mem_encrypt=on, mem_encrypt=off appearing later should counter that.
The same applies to the next patch, although the decompressor appears
to ignore the built-in command line entirely (I made a note of that in
the commit log)
Ah, makes sense.
Thanks,
Tom
