Re: [PATCH v5 0/7] x86/boot: Remove run-time relocations from compressed kernel

[Ard Biesheuvel]

On Fri, 17 Jul 2020 at 21:17, Nick Desaulniers <ndesaulniers@xxxxxxxxxx> wrote:
>
> On Fri, Jul 17, 2020 at 6:46 AM Arvind Sankar <nivedita@xxxxxxxxxxxx> wrote:
> >
> > On Tue, Jul 14, 2020 at 08:41:26PM -0400, Arvind Sankar wrote:
> > > The compressed kernel currently contains bogus run-time relocations in
> > > the startup code in head_{32,64}.S, which are generated by the linker,
> > > but must not actually be processed at run-time.
> > >
> > > This generates warnings when linking with the BFD linker, and errors
> > > with LLD, which defaults to erroring on run-time relocations in read-only
> > > sections. It also requires the -z noreloc-overflow hack for the 64-bit
> > > kernel, which prevents us from linking it as -pie on an older BFD linker
> > > (<= 2.26) or on LLD, because the locations that are to be apparently
> > > relocated are only 32-bits in size and so cannot really have
> > > R_X86_64_RELATIVE relocations.
> > >
> > > This series aims to get rid of these relocations. I've build- and
> > > boot-tested with combinations of clang/gcc-10 with lld/bfd-2.34, and
> > > gcc-4.9.0 with bfd-2.24, skipping clang on 32-bit because it currently
> > > has other issues [0].
> > >
> >
> > Hi Thomas, Ingo, Borislav, would you be able to take a look over this
> > series in time for 5.9?
>
> Hi Arvind, thanks for the series; I'm behind on testing.  When I try
> to apply this series on top of linux-next, I get a collision in
> drivers/firmware/efi/libstub/Makefile:27 when applying "0002
> x86/boot/compressed: Force hidden visibility for all symbol
> references". Would you mind refreshing the series to avoid that
> collision?

That is not the right way to deal with conflicts against -next.

This series targets the -tip tree, and applies fine against it. If you
want to apply it on some other tree and test it, that is fine, and
highly appreciated, but 'refreshing' the series against -next means it
no longer applies to -tip, and may be based on unidentified conflict
resolutions performed by Stephen that the maintainers will have to
deal with.

Boris, Ingo, Thomas,

Mind taking v5 of this series? (With Nick's Tested-by) I think these
patches have been simmering long enough. Do note there is a conflict
against the kbuild tree, but the resolution should be straightforward.