Re: runtime validation of DT_SYMTAB lookups - why is there no DT_SYMSZ?

[Mark Wielaard <mark@klomp.org>]

Hi Milian,

On Wed, 2022-07-27 at 13:38 +0200, Milian Wolff wrote:
> Thanks for confirming that this isn't available currently. Would it
> be 
> possible to add this? What's the process for standardization here? I guess it 
> would take a very long time, yet this seems to me as if it would be beneficial 
> in the long term.

Standardization of the ELF gabi takes place on (sorry google groups, I
know, sigh): https://groups.google.com/g/generic-abi you should be able
to subscribe with generic-abi+subscribe@googlegroups.com so you don't
have to go through the webgui mess.

There is also https://sourceware.org/gnu-gabi/ but that is more for GNU
extensions and I think you want something generic.

> > Di Chen recently
> > (or actually not that recently, I just still haven't reviewed,
> > sorry!)
> > posted a patch for
> > https://sourceware.org/bugzilla/show_bug.cgi?id=28873 to print out
> > the
> > symbols from the dynamic segment
> > https://sourceware.org/pipermail/elfutils-devel/2022q2/005086.html
> 
> Interesting. But from what I can tell, this patch has access to the
> full Elf 
> object and thus can access segments which are not normally loaded at
> runtime?

Yes it could, but it doesn't use anything that isn't referenced from
the phdrs or dynamic segment, so it only uses those parts that are
normally loaded at runtime. If you go through the dynamic segment then
everything it references (.dynsym in this case) is from a loaded
segment. So going through phdrs to check where it is loaded and the
length is fine.

> Try with eu-elflint --gnu which suppresses some known issues.
> 
> Indeed, with `--gnu` the tool reports `No errors`.
> 
> > Also could you show those symbol values (1272, 3684, 25720, 27227)
> > they
> > might have a special type, so their st_value isn't really an
> > address?
> 
> ```
> $ eu-readelf -s libQt5Qml.so.5.12.0 | grep -E
> "^\s*(1272|3684|25720|27227):"
>  1272: 003f9974      0 NOTYPE  GLOBAL DEFAULT       25
> __bss_start__@@Qt_5
>  3684: 003f9974      0 NOTYPE  GLOBAL DEFAULT       25
> __bss_start@@Qt_5
>  1272: 003ccc4c      0 NOTYPE  LOCAL  DEFAULT       17 $d
>  3684: 003cbfec      0 NOTYPE  LOCAL  DEFAULT       17 $d
> 25720: 003f9974      0 NOTYPE  GLOBAL DEFAULT       25 __bss_start
> 27227: 003f9974      0 NOTYPE  GLOBAL DEFAULT       25 __bss_start__
> ```
> 
> The first two matches come from the `.dynsym`, the last four come
> from 
> `.symtab`.
> 
> Can anyone tell me how `eu-readelf` resolves these symbol names?

Currently through the section tables, which point to the string table
section used. But Di Chen's patch would change that by going through
the dynamic segment and phdrs to find the strtab for the dynsym segment
(but will of course still need to go through the sections for the
.symtab symbols since those aren't accessible through the phdrs).

Cheers,

Mark