On Tue, Jan 07, 2020 at 03:13:46PM +0100, Ard Biesheuvel wrote: > On Tue, 7 Jan 2020 at 15:01, Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> wrote: > > > > On Tue, 7 Jan 2020 at 14:55, Arvind Sankar <nivedita@xxxxxxxxxxxx> wrote: > > > > > > This series performs GOT relocation before calling into C code for the > > > EFI stub. While the stub does not currently require GOT relocation, it's > > > quite easy to introduce code that will use the GOT on old toolchains, > > > but not recent ones, which can lead to unexpected issues. > > > > > > This is based on > > > https://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git/log/?h=next > > > > > > with commit 4169bb99cd70 ("efi/libstub/x86: use mandatory 16-byte stack > > > alignment in mixed mode") reverted, as it caused a crash in mixed mode. > > > > > > > Hi Arvind, > > > > I appreciate the effort, but I really don't think this is a good idea. > > > > A GOT is completely pointless in bare metal code, and fortunately, > > modern toolchains make it easier to suppress GOT entries from being > > emitted. So instead of adding back asm code that I just removed, I > > think it would be better to investigate whether we can get rid of the > > GOT entirely. > > > > With the following added to arch/x86/boot/compressed/vmlinux.lds.S, > the 64-bit kernel already links without error. > > ASSERT (_got == _egot, "GOT entries detected"); > > The 32-bit kernel produces a GOT with 3 entries: I'm trying to narrow > down where they come from. > > With modern toolchain, 32-bit compressed kernel doesn't actually use the GOT, however unlike 64-bit, the linker still emits a GOT with the three reserved entries. The rest of the early boot code (after EFI stub) does generate R_386_GOT32(X) relocations, so we need to use a GOT anyway to cater for older linkers. Having a build-time check that the EFI stub code does not have any such relocations might be possible, but it seems easier to just do the GOT processing for it as well.
