On Thu, Jan 02, 2020 at 05:59:27PM +0100, Ard Biesheuvel wrote: > On Thu, 2 Jan 2020 at 17:28, Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> wrote: > > > > On Thu, 2 Jan 2020 at 16:58, Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> wrote: > > > > > > On Thu, 2 Jan 2020 at 16:51, Arvind Sankar <nivedita@xxxxxxxxxxxx> wrote: > > > > > > > > On Thu, Jan 02, 2020 at 04:20:46PM +0100, Ard Biesheuvel wrote: > > > > > > > > > > Yeah, good point. > > > > > > > > > > I pushed as branch here; > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/log/?h=efi-libstub-attr-const > > > > > > > > > > Could you please check if that fixes the issue for efi_is_64bit() ? > > > > > > > > Haven't built it yet -- but how does this handle the GOT issues you > > > > mentioned? > > > > > > It doesn't. The trick is to add __attribute__((visibility("hidden"))) > > > to the extern declaration of efi_is64, but I am having trouble to > > > reproduce the original issue. > > > > Some background: > > > > https://lore.kernel.org/lkml/5405E186.2080406@xxxxxxxxxxxxx/ > > https://lore.kernel.org/lkml/20140919104021.GA11552@xxxxxxxxx/ > > OK, I have done a bit more digging, and it seems like recent > toolchains can optimize away GOT indirections using R_386_GOT32X > relocations, which can be converted into R_386_GOTOFF relocations by > the linker if it is building a fully linked binary, making the actual > contents of the GOT entries irrelevant. > > Note that even if the GOT entries are not fixed up, assigning a global > variable and then using it again may work by accident if the memory it > points to is writable, which is why it is not easy to reproduce > reliably. > > efi_is64 only exists on 64-bit, so annotating that as 'hidden' should > work. But efi_system_table() is also used on 32-bit, so I'll leave > that one alone for now. With hidden visibility, 32-bit compiler seems to generate GOTOFF relocations directly so it shouldn't depend on recent toolchain? https://godbolt.org/z/79iA_3
