On Tue, 22 Nov 2022 at 22:37, Ard Biesheuvel <ardb@xxxxxxxxxx> wrote:
On Tue, 22 Nov 2022 at 21:48, Tom Lendacky <thomas.lendacky@xxxxxxx> wrote:
On 11/22/22 10:10, Ard Biesheuvel wrote:
After doing some cleanup work on the EFI code in head_64.S, the mixed
mode code in particular, I noticed that the memory encryption pieces
could use some attention as well, so I cleaned that up too.
Changes since v2:
- add some clarifying comments to the EFI mixed mode changes
- include patch to make the EFI handover protocol optional that was sent
out separately before
- rebase onto tip/master
Changes since v1:
- at Boris's request, split the patches into smaller ones that are
easier to review
Cc: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
Cc: Ingo Molnar <mingo@xxxxxxxxxx>
Cc: Borislav Petkov <bp@xxxxxxxxx>
Cc: Dave Hansen <dave.hansen@xxxxxxxxxxxxxxx>
Cc: Michael Roth <michael.roth@xxxxxxx>
This causes an SEV guest to blow up on boot in the early boot code. It
looks like the stack pointer is not valid and it triple faults on a pushq
instruction (pushq $__KERNEL_CS in arch/x86/boot/compressed/head_64.S of
startup_64).
Thanks for the report.
So the mystery here (at least to me) is that all the changes are to
the 32-bit code, and startup_64 reloads the stack pointer from the
symbol
Does your config have CONFIG_EFI_MIXED enabled?
Can I reproduce this fully emulated with QEMU? Or do I need a SEV host?
Also, mind giving this a quick spin?
diff --git a/drivers/firmware/efi/libstub/x86-stub.c
b/drivers/firmware/efi/libstub/x86-stub.c
index cb5f0befee57..1af11d34bc6c 100644
--- a/drivers/firmware/efi/libstub/x86-stub.c
+++ b/drivers/firmware/efi/libstub/x86-stub.c
@@ -23,7 +23,7 @@
const efi_system_table_t *efi_system_table;
const efi_dxe_services_table_t *efi_dxe_table;
-u32 image_offset;
+u32 __section(".data") image_offset;
static efi_loaded_image_t *image = NULL;
static efi_status_t
Thanks,
Ard.