Re: [PATCH v2 00/21] efi/x86: confine type unsafe casting to mixed mode

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

 



On Thu, 19 Dec 2019 at 13:12, Hans de Goede <hdegoede@xxxxxxxxxx> wrote:
>
> Hi,
>
> On 18-12-2019 18:01, Ard Biesheuvel wrote:
> > Currently, we support mixed mode (64-bit Linux running on 32-bit firmware)
> > by explicitly reasoning about pointer sizes for every call into the
> > firmware: on x86, there are 32-bit and 64-bit versions of each protocol
> > interface, and each call gets routed via one of the two, depending on the
> > native size of the firmware.
> >
> > There is a lot of casting and pointer mangling involved in this, and as
> > a result, we end up with much less coverage in terms of type checking by
> > the compiler, due to the indirection via an anonymous, variadic thunking
> > routine.
> >
> > This peculiarity of x86 is also leaking into generic EFI code, which is
> > shared with ia64, arm64, ARM and likely RiscV in the future. So let's
> > try to clean this up a bit.
> >
> > The approach taken by this series is to replace the 32/64 bit distinction
> > with a distinction between native calls and mixed mode calls, where the
> > former can be either 32 or 64 bit [depending on the platform] and use
> > the ordinary native protocol definitions, while mixed mode calls retain
> > the existing casting/thunking approach based on the 32-bit protocol
> > definitions.
> >
> > Given that GCC now supports emitting function calls using the MS calling
> > convention, we can get rid of all the wrapping and casting, and emit the
> > indirect calls directly.
> >
> > Changes since v1:
> > - Substantially more cleanup work to simplify and hide the mixed mode handling
> >    in generic EFI code.
> > - Get rid of all the pointless passing around of sys_table_arg
> > - Incorporate an updated version of Matthew's PCI DMA disable patch using EFI
> >    events to defer poking the busmaster bits until after all the ordinary
> >    ExitBootServices() callbacks have executed.
> >
> > Code can be found here
> > https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/log/?h=efistub-x86-cleanup-v2
> >
> > Cc: Hans de Goede <hdegoede@xxxxxxxxxx>
> > Cc: Matthew Garrett <matthewgarrett@xxxxxxxxxx>
> > Cc: Ingo Molnar <mingo@xxxxxxxxxx>
> > Cc: Andy Lutomirski <luto@xxxxxxxxxx>
> > Cc: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
> > Cc: Arvind Sankar <nivedita@xxxxxxxxxxxx>
>
> I've merged ardb/efistub-x86-cleanup-v3 into my local tree for testing I will let
> you know if I see any unexpected side-effects. I've set CONFIG_EFI_DISABLE_PCI_DMA=n
> for now.
>

Thanks Hans.

The CONFIG should not make a difference on mixed-mode - all the code
is there anyway, and only the default value changes, but it is
overridden to 'false' on mixed mode systems. The reason is that my
version of this patch uses an event callback, which would mean 32-bit
firmware calling back into the 64-bit kernel in the mixed mode case,
which we don't support.



> I did notice one small cosmetic issue with the last patch:
>
>  > diff --git a/drivers/firmware/efi/Kconfig b/drivers/firmware/efi/Kconfig
>  > index bcc378c19ebe..da2f5fc862aa 100644
>  > --- a/drivers/firmware/efi/Kconfig
>  > +++ b/drivers/firmware/efi/Kconfig
>  > @@ -215,6 +215,28 @@ config EFI_RCI2_TABLE
>  >
>  >        Say Y here for Dell EMC PowerEdge systems.
>  >
>  > +config EFI_DISABLE_PCI_DMA
>  > +       bool "Clear Busmaster bit on PCI bridges during ExitBootServices()"
>  > +       help
>
> The bool and help here seem to be indented by 7 spaces rather then by a tab.
>
> Regards,
>
> Hans
>
>



[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