On 24 June 2018 at 15:43, Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote: > On Sun, 24 Jun 2018, Ard Biesheuvel wrote: >> On 24 June 2018 at 15:16, Hans de Goede <hdegoede@xxxxxxxxxx> wrote: >> > Ard, thank you for Cc-ing me on this. >> > >> > I've tested a 64 bit kernel build on a 32 bit UEFI firmware (so mixed mode) >> > and this patch causes a reboot loop there. I do get grub (no surprise there >> > as grub is unchanged), but as soon as the kernel loads the device resets. >> > >> > So I think we need some special casing there to deal with a 64 bit kernel >> > calling into 32 bit UEFI. >> > >> >> OK, so mixed mode rears its ugly hand again :-( >> >> Considering we had other weird issues involving uint64_t types with >> the TPM code just this week, I wonder if this isn't a fundamental >> problem with the mixed mode thunking, and so I need some help from the >> x86 gurus (Ingo?) >> >> If the thunking code simply maps each 64-bit argument onto a 32-bit >> stack slot, it is obvious that passing uint64_t type arguments is >> impossible. >> >> So would it be possible to have a efi_config::call() variant that is >> annotated as expecting the i386 calling convention, and let the >> compiler handle this? All we'd need to do in the mixed mode thunking >> code is pushing an additional word [as we do know] for the function >> pointer. > > Grumbl. This thing just went into rc2 a few minutes ago. > Good. Without that patch, 64-bit Linux on 64-bit EFI is broken, which is much worse. It seems mixed mode is fundamentally broken anyway, so we can take a bit of time to fix it properly -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
