V5 [PATCH 2/2] ldconfig/x86: Add ISA level check to glibc-hwcaps

[H.J. Lu]

On Tue, Dec 8, 2020 at 6:18 AM Florian Weimer <fweimer@redhat.com> wrote:
>
> * H. J. Lu:
>
> > On Tue, Dec 8, 2020 at 5:32 AM Florian Weimer <fweimer@redhat.com> wrote:
> >>
> >> * H. J. Lu:
> >>
> >> > On Mon, Dec 7, 2020 at 2:00 AM Florian Weimer <fweimer@redhat.com> wrote:
> >> >>
> >> >> * H. J. Lu via Libc-alpha:
> >> >>
> >> >> > Add ISA level check to detect misplaced shared objects with incompatible
> >> >> > ISA level requirement in glibc-hwcaps subdirectories:
> >> >> >
> >> >> > /sbin/ldconfig: /usr/lib64/glibc-hwcaps/x86-64-v2/libx86-64-isa-level.so: skipped, ISA level mismatch (x86-64-v4 > x86-64-v2)
> >> >>
> >> >> I think this is conceptually the wrong approach.  ldconfig should copy
> >> >> the notes into the cache (and aux cache), and ld.so should skip cache
> >> >> contents that doesn't match the run-time requirements during load.  Then
> >> >> directory place does not matter that much anymore.
> >> >
> >> > Do we have space in cache for it?
> >>
> >> We have an extension mechanism.  The relevant struct looks like this:
> >>
> >> struct file_entry_new
> >> {
> >>   int32_t flags;                /* This is 1 for an ELF library.  */
> >>   uint32_t key, value;  /* String table indices.  */
> >>   uint32_t osversion;           /* Required OS version.  */
> >>   uint64_t hwcap;               /* Hwcap entry.  */
> >> };
> >>
> >> We can set a previously-unused bit hwcap to hide entries from current
> >> ld.so.  This way, we can repurpose other hwcap bits, osversion, even
> >> flags.  We could put an index there into a array of (property) notes,
> >> and use deduplication to share identical notes from different shared
> >> objects.
> >>
> >> In essence, this is how the glibc-hwcaps subdirectory mechanism achieves
> >> backwards-compatibility.
> >>
> >
> > For each file entry for a shared object, the hwcap field has been used by
> > DL_CACHE_HWCAP_EXTENSION for glibc-hwcaps.  Are you suggesting
> > to add another file entry for the same shared object to store ISA level
> > requirement?
>
> It's a 64-bit field.  We do this:
>
> /* This bit in the hwcap field of struct file_entry_new indicates that
>    the lower 32 bits contain an index into the
>    cache_extension_tag_glibc_hwcaps section.  Older glibc versions do
>    not know about this HWCAP bit, so they will ignore these
>    entries.  */
> #define DL_CACHE_HWCAP_EXTENSION (1ULL << 62)
>
> /* Return true if the ENTRY->hwcap value indicates that
>    DL_CACHE_HWCAP_EXTENSION is used.  */
> static inline bool
> dl_cache_hwcap_extension (struct file_entry_new *entry)
> {
>   /* If DL_CACHE_HWCAP_EXTENSION is set, but other bits as well, this
>      is a different kind of extension.  */
>   return (entry->hwcap >> 32) == (DL_CACHE_HWCAP_EXTENSION >> 32);
> }
>
> So we can use a different bit pattern involving DL_CACHE_HWCAP_EXTENSION
> to express something else.  In particular, only the lower 32 bits are
> currently used as an index.

So bits 33-47 can be used for ISA level requirement.  This should support
65536 ISA levels.

-- 
H.J.