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

[Florian Weimer]

* 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.

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill