From: Arvind Sankar <nivedita@alum.mit.edu> To: Ard Biesheuvel <ardb@kernel.org> Cc: Arvind Sankar <nivedita@alum.mit.edu>, Borislav Petkov <bp@alien8.de>, Sergey Shatunov <me@prok.pw>, hpa@zytor.com, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, mingo@redhat.com, Thomas Gleixner <tglx@linutronix.de>, x86@kernel.org, linux-efi <linux-efi@vger.kernel.org>, initramfs@vger.kernel.org, Donovan Tremura <neurognostic@protonmail.ch>, Harald Hoyer <harald@hoyer.xyz> Subject: Re: [PATCH 1/2] x86/boot/compressed/64: Remove .bss/.pgtable from bzImage Date: Mon, 6 Apr 2020 12:52:43 -0400 [thread overview] Message-ID: <20200406165243.GA303819@rani.riverdale.lan> (raw) In-Reply-To: <CAMj1kXFKDWB9n0kWhXHLH0XP0O1v_0b=bFJad=kBvx2qVxqDcQ@mail.gmail.com> On Mon, Apr 06, 2020 at 06:22:33PM +0200, Ard Biesheuvel wrote: > > > We could just pull the stub's bss section all into data with objcopy > > similar to what ARM64 does [1]? i.e. rename .bss to .bss.efistub and > > then pull that into .data in the linker script for the compressed > > kernel? > > > > I don't follow. I'm not aware of arm64 doing anything out of the > ordinary with .bss? Note that arm64 does not have a separate > decompressor, so the EFI stub is part of the kernel proper. This is > why sections are renamed to start with .init ARM64 renames the stub sections prefixing them with .init, and that includes .bss. The ARM64 linker script then puts .init.bss into the .init.data section. So I was suggesting doing something similar with the x86 stub, renaming .bss to .bss.efistub, and then putting that into .data via linker script. Anyway, I'll do the section annotation for now as that will be less churn and we can revisit this after that. > > > There is also this scary looking comment in gnu-efi's linker script: > > /* the EFI loader doesn't seem to like a .bss section, so we stick > > it all into .data: */ > > I don't know what the history of that is. > > > > I don't remember, to be honest, but I'm pretty sure I copy-pasted that > from elsewhere at the time. > > > [1] As an aside, why doesn't ARM do this as well rather than using the > > section(.data) annotation? > > > > The ARM decompressor has this hideous hack, where text [and rodata] > executes straight from flash, and BSS is relocated into DRAM. In order > for this to work, it actually *requires* GOT indirections for BSS > items, to ensure that all BSS references use absolute addresses, which > can be relocated independently from the rest of the kernel image. This > is the reason ARM does not permit a .data section in the decompressor. > However, the EFI stub does not support execute in place from flash, > and so we can permit a .data section there. At the same time, we don't > support GOT indirections in the EFI stub, so we cannot use the BSS > section. So instead, we just put the few BSS pieces we have into .data > instead. > I see, thanks.
WARNING: multiple messages have this Message-ID (diff)
From: Arvind Sankar <nivedita-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org> To: Ard Biesheuvel <ardb-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> Cc: Arvind Sankar <nivedita-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>, Borislav Petkov <bp-Gina5bIWoIWzQB+pC5nmwQ@public.gmane.org>, Sergey Shatunov <me-fHUSW+XspFU@public.gmane.org>, hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org, Linux Kernel Mailing List <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, mingo-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>, x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, linux-efi <linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, initramfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Donovan Tremura <neurognostic-g/b1ySJe57IkP3XJZ0H8fw@public.gmane.org>, Harald Hoyer <harald-PnQE6hpDOpmlVyrhU4qvOw@public.gmane.org> Subject: Re: [PATCH 1/2] x86/boot/compressed/64: Remove .bss/.pgtable from bzImage Date: Mon, 6 Apr 2020 12:52:43 -0400 [thread overview] Message-ID: <20200406165243.GA303819@rani.riverdale.lan> (raw) In-Reply-To: <CAMj1kXFKDWB9n0kWhXHLH0XP0O1v_0b=bFJad=kBvx2qVxqDcQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> On Mon, Apr 06, 2020 at 06:22:33PM +0200, Ard Biesheuvel wrote: > > > We could just pull the stub's bss section all into data with objcopy > > similar to what ARM64 does [1]? i.e. rename .bss to .bss.efistub and > > then pull that into .data in the linker script for the compressed > > kernel? > > > > I don't follow. I'm not aware of arm64 doing anything out of the > ordinary with .bss? Note that arm64 does not have a separate > decompressor, so the EFI stub is part of the kernel proper. This is > why sections are renamed to start with .init ARM64 renames the stub sections prefixing them with .init, and that includes .bss. The ARM64 linker script then puts .init.bss into the .init.data section. So I was suggesting doing something similar with the x86 stub, renaming .bss to .bss.efistub, and then putting that into .data via linker script. Anyway, I'll do the section annotation for now as that will be less churn and we can revisit this after that. > > > There is also this scary looking comment in gnu-efi's linker script: > > /* the EFI loader doesn't seem to like a .bss section, so we stick > > it all into .data: */ > > I don't know what the history of that is. > > > > I don't remember, to be honest, but I'm pretty sure I copy-pasted that > from elsewhere at the time. > > > [1] As an aside, why doesn't ARM do this as well rather than using the > > section(.data) annotation? > > > > The ARM decompressor has this hideous hack, where text [and rodata] > executes straight from flash, and BSS is relocated into DRAM. In order > for this to work, it actually *requires* GOT indirections for BSS > items, to ensure that all BSS references use absolute addresses, which > can be relocated independently from the rest of the kernel image. This > is the reason ARM does not permit a .data section in the decompressor. > However, the EFI stub does not support execute in place from flash, > and so we can permit a .data section there. At the same time, we don't > support GOT indirections in the EFI stub, so we cannot use the BSS > section. So instead, we just put the few BSS pieces we have into .data > instead. > I see, thanks.
next prev parent reply other threads:[~2020-04-06 16:52 UTC|newest] Thread overview: 130+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-01-09 15:02 [PATCH 1/2] x86/boot/compressed/64: Remove .bss/.pgtable from bzImage Arvind Sankar 2020-01-09 15:02 ` [PATCH 2/2] x86/boot/compressed: Remove unnecessary sections " Arvind Sankar 2020-02-06 11:44 ` Kees Cook 2020-02-19 16:55 ` [tip: x86/boot] " tip-bot2 for Arvind Sankar 2020-02-22 5:08 ` [PATCH 2/2] " Nathan Chancellor 2020-02-22 6:55 ` Borislav Petkov 2020-02-22 7:02 ` Nathan Chancellor 2020-02-22 7:21 ` Fangrui Song 2020-02-22 7:42 ` Nathan Chancellor 2020-02-22 15:37 ` Arvind Sankar 2020-02-22 16:44 ` Arvind Sankar 2020-02-22 17:18 ` [PATCH] x86/boot/compressed: Fix compressed kernel linking with lld Arvind Sankar 2020-02-22 18:14 ` Nathan Chancellor 2020-02-22 18:58 ` Fangrui Song 2020-02-22 20:17 ` Arvind Sankar 2020-02-22 21:01 ` Fangrui Song 2020-02-22 23:33 ` Nick Desaulniers 2020-02-22 23:57 ` Arvind Sankar 2020-02-23 19:37 ` [PATCH 0/2] Stop generating .eh_frame sections Arvind Sankar 2020-02-24 4:15 ` Nathan Chancellor 2020-02-24 20:49 ` Nick Desaulniers 2020-02-24 21:53 ` Arvind Sankar 2020-02-24 22:01 ` Nick Desaulniers 2020-02-23 19:37 ` [PATCH 1/2] arch/x86: Use -fno-asynchronous-unwind-tables to suppress " Arvind Sankar 2020-02-24 20:33 ` Nick Desaulniers 2020-02-24 21:05 ` Arvind Sankar 2020-02-24 21:12 ` Fangrui Song 2020-02-24 21:17 ` Nick Desaulniers 2020-02-24 21:22 ` Nick Desaulniers 2020-02-23 19:37 ` [PATCH 2/2] arch/x86: Drop unneeded linker script discard of .eh_frame Arvind Sankar 2020-02-24 20:45 ` Nick Desaulniers 2020-02-24 21:33 ` Arvind Sankar 2020-02-24 21:58 ` Nick Desaulniers 2020-02-24 23:21 ` [PATCH v2 0/2] Stop generating .eh_frame sections Arvind Sankar 2020-02-24 23:21 ` [PATCH v2 1/2] arch/x86: Use -fno-asynchronous-unwind-tables to suppress " Arvind Sankar 2020-02-24 23:28 ` Nathan Chancellor 2020-02-24 23:30 ` Nick Desaulniers 2020-02-25 4:10 ` Kees Cook 2020-02-25 16:53 ` [tip: x86/boot] x86/*/Makefile: " tip-bot2 for Arvind Sankar 2020-02-24 23:21 ` [PATCH v2 2/2] arch/x86: Drop unneeded linker script discard of .eh_frame Arvind Sankar 2020-02-24 23:28 ` Nathan Chancellor 2020-02-24 23:33 ` Nick Desaulniers 2020-02-25 4:11 ` Kees Cook 2020-02-25 16:53 ` [tip: x86/boot] x86/vmlinux: " tip-bot2 for Arvind Sankar 2020-02-23 22:00 ` [PATCH] x86/boot/compressed: Fix compressed kernel linking with lld Kees Cook 2020-02-24 6:06 ` Fangrui Song 2020-02-22 17:29 ` [PATCH 2/2] x86/boot/compressed: Remove unnecessary sections from bzImage Borislav Petkov 2020-02-22 17:53 ` Arvind Sankar 2020-02-22 7:42 ` Borislav Petkov 2020-02-22 16:22 ` Arvind Sankar 2020-02-22 23:20 ` Nick Desaulniers 2020-02-24 13:28 ` Michael Matz 2020-02-24 20:51 ` Nick Desaulniers 2020-02-24 21:28 ` Fangrui Song 2020-02-24 21:48 ` Arvind Sankar 2020-02-24 22:17 ` Fangrui Song 2020-02-24 22:43 ` Arvind Sankar 2020-02-24 22:50 ` Fangrui Song 2020-02-24 23:08 ` Arvind Sankar 2020-02-25 5:35 ` --orphan-handling=warn (was Re: [PATCH 2/2] x86/boot/compressed: Remove unnecessary sections) " Kees Cook 2020-02-25 16:42 ` --orphan-handling=warn Arvind Sankar 2020-02-25 18:29 ` --orphan-handling=warn Arvind Sankar 2020-02-25 19:42 ` --orphan-handling=warn Kees Cook 2020-02-25 20:37 ` --orphan-handling=warn Nick Desaulniers 2020-02-25 22:02 ` --orphan-handling=warn Kees Cook 2020-02-26 1:56 ` --orphan-handling=warn Fangrui Song 2020-02-26 5:35 ` --orphan-handling=warn Kees Cook 2020-02-26 19:11 ` --orphan-handling=warn Kristen Carlson Accardi 2020-02-26 19:26 ` --orphan-handling=warn Nick Desaulniers 2020-02-24 11:37 ` [tip: x86/boot] x86/boot/compressed: Remove .eh_frame section from bzImage tip-bot2 for Arvind Sankar 2020-02-24 16:41 ` Arvind Sankar 2020-02-24 17:16 ` Borislav Petkov 2020-02-24 17:28 ` Arvind Sankar 2020-02-05 16:29 ` [PATCH 1/2] x86/boot/compressed/64: Remove .bss/.pgtable " Arvind Sankar 2020-02-18 18:03 ` Arvind Sankar 2020-02-19 12:09 ` Borislav Petkov 2020-02-19 17:57 ` Arvind Sankar 2020-02-19 18:22 ` Borislav Petkov 2020-02-19 19:06 ` Arvind Sankar 2020-02-06 11:18 ` Kees Cook 2020-02-19 16:55 ` [tip: x86/boot] " tip-bot2 for Arvind Sankar 2020-04-05 15:42 ` [PATCH 1/2] " Sergey Shatunov 2020-04-05 23:18 ` Arvind Sankar 2020-04-06 0:00 ` Sergey Shatunov 2020-04-06 3:51 ` Arvind Sankar 2020-04-06 3:51 ` Arvind Sankar 2020-04-06 7:32 ` Ard Biesheuvel 2020-04-06 8:47 ` Borislav Petkov 2020-04-06 9:11 ` Ard Biesheuvel 2020-04-06 9:11 ` Ard Biesheuvel 2020-04-06 11:20 ` Borislav Petkov 2020-04-06 11:20 ` Borislav Petkov 2020-04-06 13:22 ` Arvind Sankar 2020-04-06 13:29 ` Ard Biesheuvel 2020-04-06 13:29 ` Ard Biesheuvel 2020-04-06 16:01 ` Arvind Sankar 2020-04-06 16:01 ` Arvind Sankar 2020-04-06 16:22 ` Ard Biesheuvel 2020-04-06 16:22 ` Ard Biesheuvel 2020-04-06 16:52 ` Arvind Sankar [this message] 2020-04-06 16:52 ` Arvind Sankar 2020-04-06 16:59 ` Ard Biesheuvel 2020-04-06 18:06 ` [PATCH 1/2] efi/x86: Move efi stub globals from .bss to .data Arvind Sankar 2020-04-06 18:06 ` Arvind Sankar 2020-04-06 18:06 ` [PATCH 2/2] efi/x86: Always relocate the kernel for EFI handover entry Arvind Sankar 2020-04-14 8:20 ` [tip: efi/urgent] " tip-bot2 for Arvind Sankar 2020-04-06 18:29 ` [PATCH 1/2] efi/x86: Move efi stub globals from .bss to .data Ard Biesheuvel 2020-04-06 18:29 ` Ard Biesheuvel 2020-04-08 7:43 ` Dave Young 2020-04-08 7:43 ` Dave Young 2020-04-08 7:49 ` Ard Biesheuvel 2020-04-08 7:49 ` Ard Biesheuvel 2020-04-09 14:39 ` Arvind Sankar 2020-04-09 14:47 ` Ard Biesheuvel 2020-04-09 16:35 ` Arvind Sankar 2020-04-09 16:35 ` Arvind Sankar 2020-04-10 14:47 ` Arvind Sankar 2020-04-10 14:47 ` Arvind Sankar 2020-04-10 15:26 ` Ard Biesheuvel 2020-04-14 14:57 ` Daniel Kiper 2020-04-14 14:57 ` Daniel Kiper 2020-04-10 11:26 ` Thomas Meyer 2020-04-10 14:38 ` Arvind Sankar 2020-04-11 8:50 ` Thomas Meyer 2020-04-14 8:20 ` [tip: efi/urgent] " tip-bot2 for Arvind Sankar 2020-04-06 17:21 ` [PATCH 1/2] x86/boot/compressed/64: Remove .bss/.pgtable from bzImage Borislav Petkov 2020-04-06 17:21 ` Borislav Petkov 2020-04-06 8:44 ` Ard Biesheuvel 2020-04-06 12:36 ` Sergey Shatunov 2020-04-06 13:20 ` Ard Biesheuvel
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=20200406165243.GA303819@rani.riverdale.lan \ --to=nivedita@alum.mit.edu \ --cc=ardb@kernel.org \ --cc=bp@alien8.de \ --cc=harald@hoyer.xyz \ --cc=hpa@zytor.com \ --cc=initramfs@vger.kernel.org \ --cc=linux-efi@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=me@prok.pw \ --cc=mingo@redhat.com \ --cc=neurognostic@protonmail.ch \ --cc=tglx@linutronix.de \ --cc=x86@kernel.org \ /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: linkBe 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.