[PATCH v5 09/11] elf: Add glibc-hwcaps subdirectory support to ld.so cache processing
Szabolcs Nagy
szabolcs.nagy@arm.com
Tue Dec 22 22:30:46 GMT 2020
The 12/01/2020 21:48, Florian Weimer via Libc-alpha wrote:
> This recognizes the DL_CACHE_HWCAP_EXTENSION flag in cache entries,
> and picks the supported cache entry with the highest priority.
>
> The elf/tst-glibc-hwcaps-prepend-cache test documents a non-desired
> aspect of the current cache implementation: If the cache selects a DSO
> that does not exist on disk, _dl_map_object falls back to open_path,
> which may or may not find an alternative implementation. This is an
> existing limitation that also applies to the legacy hwcaps processing
> for ld.so.cache.
>
> ---
> v5: Split glibc_hwcaps_priority into multiple functions. Add a DSO
> deletion test that shows non-optimal behavior.
>
> elf/Makefile | 18 ++
> elf/dl-cache.c | 194 ++++++++++++++++++++-
> elf/dl-hwcaps.c | 78 +++++++++
> elf/dl-hwcaps.h | 19 ++
> elf/tst-glibc-hwcaps-cache.c | 45 +++++
> elf/tst-glibc-hwcaps-cache.root/etc/ld.so.conf | 2 +
> elf/tst-glibc-hwcaps-cache.root/postclean.req | 0
> elf/tst-glibc-hwcaps-cache.script | 6 +
> elf/tst-glibc-hwcaps-prepend-cache.c | 150 ++++++++++++++++
> .../postclean.req | 0
> 10 files changed, 509 insertions(+), 3 deletions(-)
i see stack corruption sometimes with this test:
$ elf/ld.so --library-path ./.:elf --glibc-hwcaps-prepend prepend-markermod1 elf/tst-glibc-hwcaps-prepend --direct
works, but
$ elf/ld.so --library-path ./././././.:elf --glibc-hwcaps-prepend prepend-markermod1 elf/tst-glibc-hwcaps-prepend --direct
crashes because of stack corruption in open_path
at elf/dl-load.c:1901
1874 buf = alloca (max_dirnamelen + max_capstrlen + namelen);
...
1901 buflen =
1902 ((char *) __mempcpy (__mempcpy (edp, capstr[cnt].str,
1903 capstr[cnt].len),
1904 name, namelen)
1905 - buf);
max_dirnamelen = 11
max_capstrlen = 18
namelen = 17
i think max_capstrlen is wrong as the string is
"./././././" + "glibc-hwcaps/prepend-markermod1/" + "libmarkermod1.so"
(== 10 + 32 + 17)
but i don't know how this is supposed to work.
More information about the Libc-alpha
mailing list