Re: [PATCH] x86/efi: Fix incorrect invocation of PciIo->Attributes()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.


--
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



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux