Re: [PATCH 0/3] Relocate GOT before calling EFI stub

From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: Arvind Sankar <nivedita@alum.mit.edu>
Cc: Ard Biesheuvel <ardb@kernel.org>, linux-efi <linux-efi@vger.kernel.org>
Subject: Re: [PATCH 0/3] Relocate GOT before calling EFI stub
Date: Tue, 7 Jan 2020 20:23:34 +0100	[thread overview]
Message-ID: <CAKv+Gu8CsQOZJErDOjCtMB-6yr92CmLiCFpOTeoqdZWBOLh1oQ@mail.gmail.com> (raw)
In-Reply-To: <20200107191412.GA1685286@rani.riverdale.lan>

On Tue, 7 Jan 2020 at 20:14, Arvind Sankar <nivedita@alum.mit.edu> wrote:
>
> On Tue, Jan 07, 2020 at 08:03:18PM +0100, Ard Biesheuvel wrote:
> > On Tue, 7 Jan 2020 at 19:32, Arvind Sankar <nivedita@alum.mit.edu> wrote:
> > >
> > > On Tue, Jan 07, 2020 at 07:10:34PM +0100, Ard Biesheuvel wrote:
> > > > On Tue, 7 Jan 2020 at 19:08, Arvind Sankar <nivedita@alum.mit.edu> wrote:
> > > > >
> > > > > On Tue, Jan 07, 2020 at 06:59:57PM +0100, Ard Biesheuvel wrote:
> > > > > > On Tue, 7 Jan 2020 at 18:58, Arvind Sankar <nivedita@alum.mit.edu> wrote:
> > > > > > >
> > > > > > > On Tue, Jan 07, 2020 at 03:28:31PM +0100, Ard Biesheuvel wrote:
> > > > > > > >
> > > > > > > > Unfortunately, the command line option implements a weaker form of
> > > > > > > > visibility than the pragma, so it probably comes down to setting the
> > > > > > > > pragma in a .h file that gets -include'd via the command line so it is
> > > > > > > > guaranteed to be seen first.
> > > > > > >
> > > > > > > Tried hacking that in and it works, tested with gcc 4.6.4.
> > > > > >
> > > > > > Excellent. But in my testing locally, I don't get any GOT entries in
> > > > > > the first place, strangely enough. So what changes in the output for
> > > > > > you with visibility hidden compared to before?
> > > > >
> > > > > Works with 32-bit as well.
> > > > >
> > > > > Are you checking libstub or boot/compressed? Below is with gcc 4.6 (but
> > > > > latest binutils). With gcc 9, there's only one left -- trampoline_32bit_src
> > > > > in pgtable_64.
> > > > >
> > > >
> > > > I am looking at the size of the .got section in
> > > > boot/compressed/vmlinux, and it is 0x0 on 64-bit, and 0xc (i.e., only
> > > > the .got.plt fixup code) on 32-bit.
> > > >
> > > > Could you please check whether passing -Bsymbolic to the linker gives
> > > > the same result btw?
> > > >
> > >
> > > With new ld all those GOTPCRELX's get eliminated. If you add --no-relax
> > > you'll get them in the .got. I don't have an old version of binutils so
> > > I can't check, but I think they will be assembled as GOTPCREL and remain
> > > in the .got section after linking.
> > >
> >
> > Right, unless you use hidden visibility, no?
> >
>
> Right, that's what I said works before -- with hidden visibility the
> compiler (even an old one) does not generate any GOT-using relocations.
> We're trying to debug why you don't see any .got entries even before
> turning on hidden visibility, while I do, no?
>

Yeah. I have just reinstalled Ubuntu Trusty in a VM, which has
binutils 2.4 and has a GCC 4.6 package available, but I haven't tried
building the 64-bit kernel yet.

> > > A linker option can't help I'd think, because once these relocations are
> > > there in the object files, you need the new binutils to get rid of them.
> > > I didn't get any difference with -Bsymbolic -- also that seems to be for
> > > shared libraries, with executables the references should already be
> > > bound within the executable, shared libraries can't override them.
> >
> > PIE and .so support share a *lot* of code in binutils. In the arm64
> > kernel, we use Bsymbolic to get rid of a few absolute symbol
> > references, even though the -pie linker option should take care of
> > that, but it doesn't in all cases.