On Sun, 24 Jun 2018, Ard Biesheuvel wrote: > On 24 June 2018 at 15:43, Thomas Gleixner <[email protected]> wrote: > > On Sun, 24 Jun 2018, Ard Biesheuvel wrote: > >> On 24 June 2018 at 15:16, Hans de Goede <[email protected]> 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
Fair enough. -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
