All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: Hans de Goede <hdegoede@redhat.com>
Cc: Ard Biesheuvel <ardb@kernel.org>,
	linux-efi <linux-efi@vger.kernel.org>,
	Matthew Garrett <matthewgarrett@google.com>,
	Ingo Molnar <mingo@kernel.org>, Andy Lutomirski <luto@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Arvind Sankar <nivedita@alum.mit.edu>
Subject: Re: [PATCH v2 00/21] efi/x86: confine type unsafe casting to mixed mode
Date: Thu, 19 Dec 2019 13:22:26 +0000	[thread overview]
Message-ID: <CAKv+Gu9MLkDtvagWZYj=VxCG7QUSJdzynNzMihKtwmE1r1Qh0g@mail.gmail.com> (raw)
In-Reply-To: <34f13f7f-a79c-16be-638a-c9267b740bce@redhat.com>

On Thu, 19 Dec 2019 at 13:12, Hans de Goede <hdegoede@redhat.com> 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@redhat.com>
> > Cc: Matthew Garrett <matthewgarrett@google.com>
> > Cc: Ingo Molnar <mingo@kernel.org>
> > Cc: Andy Lutomirski <luto@kernel.org>
> > Cc: Thomas Gleixner <tglx@linutronix.de>
> > Cc: Arvind Sankar <nivedita@alum.mit.edu>
>
> 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
>
>

      reply	other threads:[~2019-12-19 13:22 UTC|newest]

Thread overview: 87+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-18 17:01 [PATCH v2 00/21] efi/x86: confine type unsafe casting to mixed mode Ard Biesheuvel
2019-12-18 17:01 ` [PATCH v2 01/21] efi/libstub: remove unused __efi_call_early() macro Ard Biesheuvel
2019-12-18 17:01 ` [PATCH v2 02/21] efi/x86: rename efi_is_native() to efi_is_mixed() Ard Biesheuvel
2019-12-18 17:01 ` [PATCH v2 03/21] efi/libstub: use a helper to iterate over a EFI handle array Ard Biesheuvel
2019-12-18 17:01 ` [PATCH v2 04/21] efi/libstub: extend native protocol definitions with mixed_mode aliases Ard Biesheuvel
2019-12-18 17:01 ` [PATCH v2 05/21] efi/libstub: distinguish between native/mixed not 32/64 bit Ard Biesheuvel
2019-12-18 17:01 ` [PATCH v2 06/21] efi/libstub/x86: use mixed mode helpers to populate efi_config Ard Biesheuvel
2019-12-18 17:01 ` [PATCH v2 07/21] efi/libstub: drop explicit 32/64-bit protocol definitions Ard Biesheuvel
2019-12-18 17:01 ` [PATCH v2 08/21] efi/libstub: use stricter typing for firmware function pointers Ard Biesheuvel
2019-12-18 17:01 ` [PATCH v2 09/21] efi/libstub: annotate firmware routines as __efiapi Ard Biesheuvel
2019-12-18 17:01 ` [PATCH v2 10/21] efi/libstub/x86: avoid thunking for native firmware calls Ard Biesheuvel
2019-12-21 21:22   ` Hans de Goede
2019-12-22 12:02     ` Ard Biesheuvel
2019-12-22 12:37       ` Ard Biesheuvel
2019-12-22 12:46       ` Andy Lutomirski
2019-12-22 15:29         ` Ard Biesheuvel
2019-12-22 21:12           ` Arvind Sankar
2019-12-22 21:25             ` Ard Biesheuvel
2019-12-23 11:49       ` Hans de Goede
2019-12-23 12:00         ` Ard Biesheuvel
2019-12-18 17:01 ` [PATCH v2 11/21] efi/libstub: get rid of 'sys_table_arg' macro parameter Ard Biesheuvel
2019-12-18 17:01 ` [PATCH v2 12/21] efi/libstub: unify the efi_char16_printk implementations Ard Biesheuvel
2019-12-18 17:01 ` [PATCH v2 13/21] efi/libstub/x86: drop __efi_early() export of efi_config struct Ard Biesheuvel
2019-12-24 19:34   ` Hans de Goede
2019-12-25 14:42     ` Ard Biesheuvel
2019-12-27 22:44       ` Hans de Goede
2019-12-27 22:51         ` Ard Biesheuvel
2019-12-31 23:04   ` Arvind Sankar
2020-01-01 18:13     ` Ard Biesheuvel
2020-01-01 19:08       ` Arvind Sankar
2020-01-02  7:33         ` Ard Biesheuvel
2020-01-02 14:06           ` Arvind Sankar
2020-01-02 15:20             ` Ard Biesheuvel
2020-01-02 15:51               ` Arvind Sankar
2020-01-02 15:58                 ` Ard Biesheuvel
2020-01-02 16:28                   ` Ard Biesheuvel
2020-01-02 16:59                     ` Ard Biesheuvel
2020-01-02 17:26                       ` Arvind Sankar
2020-01-02 17:30                         ` Ard Biesheuvel
2020-01-02 17:41                           ` Arvind Sankar
2020-01-02 17:48                             ` Ard Biesheuvel
2020-01-02 18:10                               ` Arvind Sankar
2020-01-02 18:38                                 ` Ard Biesheuvel
2020-01-03 14:16                                   ` Arvind Sankar
2020-01-03 14:23                                     ` Ard Biesheuvel
2020-01-02 18:38                               ` Arvind Sankar
2020-01-02 16:59                     ` Arvind Sankar
2020-01-02 17:03                       ` Ard Biesheuvel
2020-01-02 17:21                         ` Arvind Sankar
2019-12-18 17:01 ` [PATCH v2 14/21] efi/libstub: drop sys_table_arg from printk routines Ard Biesheuvel
2019-12-18 17:01 ` [PATCH v2 15/21] efi/libstub: remove 'sys_table_arg' from all function prototypes Ard Biesheuvel
2019-12-18 17:01 ` [PATCH v2 16/21] efi/libstub: drop protocol argument from efi_call_proto() macro Ard Biesheuvel
2019-12-18 17:01 ` [PATCH v2 17/21] efi/libstub: drop 'table' argument from efi_table_attr() macro Ard Biesheuvel
2019-12-18 17:01 ` [PATCH v2 18/21] efi/libstub: use 'func' not 'f' as macro parameter Ard Biesheuvel
2019-12-31 16:51   ` Arvind Sankar
2019-12-31 17:06     ` Ard Biesheuvel
2019-12-31 17:36       ` Arvind Sankar
2019-12-18 17:01 ` [PATCH v2 19/21] efi/libstub: tidy up types and names of global cmdline variables Ard Biesheuvel
2019-12-18 17:01 ` [PATCH v2 20/21] efi/libstub: import type definitions for creating and signalling events Ard Biesheuvel
2019-12-18 17:01 ` [PATCH v2 21/21] efi: Allow disabling PCI busmastering on bridges during boot Ard Biesheuvel
2019-12-19  2:50   ` Andy Lutomirski
2019-12-19 13:17     ` Ard Biesheuvel
2019-12-19 20:04       ` Matthew Garrett
2019-12-19 20:04   ` Matthew Garrett
2019-12-20  7:06     ` Ard Biesheuvel
2019-12-20  7:17       ` Andy Lutomirski
2019-12-20  8:11         ` Ard Biesheuvel
2019-12-20 19:41           ` Arvind Sankar
2020-01-02 14:46             ` Laszlo Ersek
2020-01-02 15:40               ` Ard Biesheuvel
2019-12-20 20:43       ` Matthew Garrett
2019-12-21 16:44         ` Ard Biesheuvel
2019-12-21 21:24           ` Matthew Garrett
2019-12-21 22:54             ` Arvind Sankar
2019-12-23 14:02               ` Ard Biesheuvel
2019-12-23 15:46                 ` Arvind Sankar
2019-12-23 15:58                   ` Ard Biesheuvel
2019-12-23 16:12                     ` Arvind Sankar
2019-12-23 20:57                   ` Matthew Garrett
2020-02-06 14:30   ` Hans de Goede
2020-02-06 14:35     ` Ard Biesheuvel
2020-03-04 10:38       ` Hans de Goede
2020-03-04 18:26         ` Ard Biesheuvel
2020-03-04 18:49           ` Hans de Goede
2020-03-04 21:59             ` Ard Biesheuvel
2019-12-19 11:12 ` [PATCH v2 00/21] efi/x86: confine type unsafe casting to mixed mode Hans de Goede
2019-12-19 13:22   ` Ard Biesheuvel [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAKv+Gu9MLkDtvagWZYj=VxCG7QUSJdzynNzMihKtwmE1r1Qh0g@mail.gmail.com' \
    --to=ard.biesheuvel@linaro.org \
    --cc=ardb@kernel.org \
    --cc=hdegoede@redhat.com \
    --cc=linux-efi@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=matthewgarrett@google.com \
    --cc=mingo@kernel.org \
    --cc=nivedita@alum.mit.edu \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.