linux-kernel - Re: [PATCH 3/9] efi/x86: Move efi stub globals from .bss to .data

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMzpN2jFbf8k99pWaTYRBmSB+iNAKYsufjEhqO6Vv0qxAcHyGA@mail.gmail.com>
Date:   Thu, 9 Apr 2020 16:53:07 -0400
From:   Brian Gerst <brgerst@...il.com>
To:     Ard Biesheuvel <ardb@...nel.org>
Cc:     linux-efi@...r.kernel.org, Ingo Molnar <mingo@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Arnd Bergmann <arnd@...db.de>,
        Arvind Sankar <nivedita@...m.mit.edu>,
        Borislav Petkov <bp@...e.de>,
        Colin Ian King <colin.king@...onical.com>,
        Gary Lin <glin@...e.com>, Jiri Slaby <jslaby@...e.cz>,
        Sergey Shatunov <me@...k.pw>, Takashi Iwai <tiwai@...e.de>
Subject: Re: [PATCH 3/9] efi/x86: Move efi stub globals from .bss to .data

On Thu, Apr 9, 2020 at 4:05 PM Brian Gerst <brgerst@...il.com> wrote:
>
> On Thu, Apr 9, 2020 at 9:07 AM Ard Biesheuvel <ardb@...nel.org> wrote:
> >
> > From: Arvind Sankar <nivedita@...m.mit.edu>
> >
> > Commit
> >
> >   3ee372ccce4d ("x86/boot/compressed/64: Remove .bss/.pgtable from bzImage")
> >
> > removed the .bss section from the bzImage.
> >
> > However, while a PE loader is required to zero-initialize the .bss
> > section before calling the PE entry point, the EFI handover protocol
> > does not currently document any requirement that .bss be initialized by
> > the bootloader prior to calling the handover entry.
> >
> > When systemd-boot is used to boot a unified kernel image [1], the image
> > is constructed by embedding the bzImage as a .linux section in a PE
> > executable that contains a small stub loader from systemd together with
> > additional sections and potentially an initrd. As the .bss section
> > within the bzImage is no longer explicitly present as part of the file,
> > it is not initialized before calling the EFI handover entry.
> > Furthermore, as the size of the embedded .linux section is only the size
> > of the bzImage file itself, the .bss section's memory may not even have
> > been allocated.
> >
> > In particular, this can result in efi_disable_pci_dma being true even
> > when it was not specified via the command line or configuration option,
> > which in turn causes crashes while booting on some systems.
> >
> > To avoid issues, place all EFI stub global variables into the .data
> > section instead of .bss. As of this writing, only boolean flags for a
> > few command line arguments and the sys_table pointer were in .bss and
> > will now move into the .data section.
> >
> > [1] https://systemd.io/BOOT_LOADER_SPECIFICATION/#type-2-efi-unified-kernel-images
> >
> > Signed-off-by: Arvind Sankar <nivedita@...m.mit.edu>
> > Reported-by: Sergey Shatunov <me@...k.pw>
> > Fixes: 3ee372ccce4d ("x86/boot/compressed/64: Remove .bss/.pgtable from bzImage")
> > Link: https://lore.kernel.org/r/20200406180614.429454-1-nivedita@alum.mit.edu
> > Signed-off-by: Ard Biesheuvel <ardb@...nel.org>
> > ---
> >  drivers/firmware/efi/libstub/efistub.h  | 2 +-
> >  drivers/firmware/efi/libstub/x86-stub.c | 2 +-
> >  2 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/firmware/efi/libstub/efistub.h b/drivers/firmware/efi/libstub/efistub.h
> > index cc90a748bcf0..67d26949fd26 100644
> > --- a/drivers/firmware/efi/libstub/efistub.h
> > +++ b/drivers/firmware/efi/libstub/efistub.h
> > @@ -25,7 +25,7 @@
> >  #define EFI_ALLOC_ALIGN                EFI_PAGE_SIZE
> >  #endif
> >
> > -#ifdef CONFIG_ARM
> > +#if defined(CONFIG_ARM) || defined(CONFIG_X86)
> >  #define __efistub_global       __section(.data)
> >  #else
> >  #define __efistub_global
> > diff --git a/drivers/firmware/efi/libstub/x86-stub.c b/drivers/firmware/efi/libstub/x86-stub.c
> > index e02ea51273ff..867a57e28980 100644
> > --- a/drivers/firmware/efi/libstub/x86-stub.c
> > +++ b/drivers/firmware/efi/libstub/x86-stub.c
> > @@ -20,7 +20,7 @@
> >  /* Maximum physical address for 64-bit kernel with 4-level paging */
> >  #define MAXMEM_X86_64_4LEVEL (1ull << 46)
> >
> > -static efi_system_table_t *sys_table;
> > +static efi_system_table_t *sys_table __efistub_global;
> >  extern const bool efi_is64;
> >  extern u32 image_offset;
> >
> > --
> > 2.17.1
> >
>
> Can we use the -fno-zero-initialized-in-bss compiler flag instead of
> explicitly marking global variables?

Scratch that.  Apparently it only works when a variable is explicitly
initialized to zero.

--
Brian Gerst