[Bug dynamic-link/25938] New: ld.so.cache should store meaning of hwcap mask bits

[Bug dynamic-link/25938] New: ld.so.cache should store meaning of hwcap mask bits

[fw at deneb dot enyo.de]

https://sourceware.org/bugzilla/show_bug.cgi?id=25938

            Bug ID: 25938
           Summary: ld.so.cache should store meaning of hwcap mask bits
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: minor
          Priority: P3
         Component: dynamic-link
          Assignee: unassigned at sourceware dot org
          Reporter: fw at deneb dot enyo.de
  Target Milestone: ---
             Flags: security-

The meaning of the bits depends on the glibc version: _DL_FIRST_EXTRA depends
on _DL_FIRST_PLATFORM and _DL_PLATFORMS_COUNT, and the latter increases if more
platform subdirectories are added (e.g., "power9").

This does not appear to be a significant issue today because the
_DL_FIRST_EXTRA mechanism was only ever used for the i686 nosegneg bit, and on
i686, _DL_FIRST_EXTRA has been unchanged for a long time.

The always-set bit for  the "tls" subdirectory is put by ldconfig at the MSB of
the 64-bit hwcap word, so its position is already constant.

However, if we ever want to reuse hwcap bits for different CPU features, the
cache needs to contain additional information about the meaning of the bits.
One way to express this mean is to list the subdirectory names the bits
correspond to.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug dynamic-link/25938] ld.so.cache should store meaning of hwcap mask bits

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=25938

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |2.33
                 CC|                            |fweimer at redhat dot com
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED
           Assignee|unassigned at sourceware dot org   |fweimer at redhat dot com

--- Comment #1 from Florian Weimer <fweimer at redhat dot com> ---
More or less fixed in glibc 2.33 by a new mechanism:

commit b44ac4f4c7a8bbe5eaa2701aa9452eaf2c96e1dd
Author: Florian Weimer <fweimer@redhat.com>
Date:   Fri Dec 4 09:13:43 2020 +0100

    elf: Process glibc-hwcaps subdirectories in ldconfig

    Libraries from these subdirectories are added to the cache
    with a special hwcap bit DL_CACHE_HWCAP_EXTENSION, so that
    they are ignored by older dynamic loaders.

    Reviewed-by: Adhemerval Zanella  <adhemerval.zanella@linaro.org>

commit 600d9e0c87940da9b0fdeff492bf888df852d40c
Author: Florian Weimer <fweimer@redhat.com>
Date:   Fri Dec 4 09:13:43 2020 +0100

    elf: Add glibc-hwcaps subdirectory support to ld.so cache processing

    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.

    Reviewed-by: Adhemerval Zanella  <adhemerval.zanella@linaro.org>

-- 
You are receiving this mail because:
You are on the CC list for the bug.