Re: [PATCH v10 02/15] livepatch: avoid position-based search if `-z unique-symbol` is available

[Josh Poimboeuf]

On Fri, Feb 11, 2022 at 10:05:02AM -0800, Fāng-ruì Sòng wrote:
> On Fri, Feb 11, 2022 at 9:41 AM Josh Poimboeuf <jpoimboe@xxxxxxxxxx> wrote:
> >
> > On Wed, Feb 09, 2022 at 07:57:39PM +0100, Alexander Lobakin wrote:
> > > Position-based search, which means that if there are several symbols
> > > with the same name, the user needs to additionally provide the
> > > "index" of a desired symbol, is fragile. For example, it breaks
> > > when two symbols with the same name are located in different
> > > sections.
> > >
> > > Since a while, LD has a flag `-z unique-symbol` which appends
> > > numeric suffixes to the functions with the same name (in symtab
> > > and strtab). It can be used to effectively prevent from having
> > > any ambiguity when referring to a symbol by its name.
> >
> > In the patch description can you also give the version of binutils (and
> > possibly other linkers) which have the flag?
> 
> GNU ld>=2.36 supports -z unique-symbol. ld.lld doesn't support -z unique-symbol.
> 
> I subscribe to llvm@xxxxxxxxxxxxxxx and happen to notice this message
> (can't keep up with the changes...)
> I am a bit concerned with this option and replied last time on
> https://lore.kernel.org/r/20220105032456.hs3od326sdl4zjv4@xxxxxxxxxx
> 
> My full reasoning is on
> https://maskray.me/blog/2020-11-15-explain-gnu-linker-options#z-unique-symbol

Ah, right.  Also discussed here:

  https://lore.kernel.org/all/20210123225928.z5hkmaw6qjs2gu5g@xxxxxxxxxx/T/#u
  https://lore.kernel.org/all/20210125172124.awabevkpvq4poqxf@treble/

I'm not qualified to comment on LTO/PGO stability issues, but it doesn't
sound good.  And we want to support livepatch for LTO kernels.

Also I realized that this flag would have a negative effect on
kpatch-build, as it currently does its analysis on .o files.  So it
would have to figure out how to properly detect function renames, to
avoid patching the wrong function for example.

And if LLD doesn't plan to support the flag then it will be a headache
for livepatch (and the kernel in general) to deal with the divergent
configs.

One idea I mentioned before, it may be worth exploring changing the "F"
in FGKASLR to "File" instead of "Function".  In other words, only
shuffle at an object-file granularity.  Then, even with duplicates, the
<file+function> symbol pair doesn't change in the symbol table.  And as
a bonus, it should help FGKASLR i-cache performance, significantly.

-- 
Josh