[PATCH 3/4] Add run-time chesk for single global definition

[Florian Weimer]

* H. J. Lu:

> On Mon, Jun 21, 2021 at 12:16 AM Florian Weimer <fweimer@redhat.com> wrote:
>>
>> * H. J. Lu via Libc-alpha:
>>
>> > +static inline void __attribute__ ((always_inline))
>> > +_dl_check_protected_symbol (const char *undef_name,
>> > +                         const struct link_map *undef_map,
>> > +                         const ElfW(Sym) *ref,
>> > +                         const struct link_map *map,
>> > +                         int type_class)
>> > +{
>> > +  if (undef_map != NULL
>> > +      && !(undef_map->l_1_needed
>> > +        & GNU_PROPERTY_1_NEEDED_SINGLE_GLOBAL_DEFINITION)
>> > +      && (map->l_1_needed
>> > +       & GNU_PROPERTY_1_NEEDED_SINGLE_GLOBAL_DEFINITION))
>> > +    {
>> > +      if ((type_class & ELF_RTYPE_CLASS_COPY))
>> > +     /* Disallow copy relocations against protected data symbols in
>> > +        an object with single global definition.  */
>> > +     _dl_fatal_printf ("copy relocation against non-copyable protected symbol=%s in file=%s\n",
>> > +                       undef_name, DSO_FILENAME (map->l_name));
>> > +      else if (ref->st_value != 0
>> > +            && ref->st_shndx == SHN_UNDEF
>> > +            && (type_class & ELF_RTYPE_CLASS_PLT))
>> > +     /* Disallow non-zero symbol values of undefined symbols, which
>> > +        are used as the function pointer, against protected function
>> > +        symbols in an object with single global definition.  */
>> > +     _dl_fatal_printf ("non-canonical reference to canonical protected function symbol=%s in file=%s\n",
>> > +                       undef_name, DSO_FILENAME (map->l_name));
>> > +    }
>> > +}
>>
>> Why are those fatal errors?
>
> 2 copies of the data symbol can be out of sync between executable and
> shared library.  We can make them as warnings with tunable to control
> it.

I meant: Why can't you turn them into regular dlopen errors that are
reported to the caller?  (Use _dl_signal_error or any of the related
functions.)

>> I have trouble understanding the second comment (for the
>> ELF_RTYPE_CLASS_PLT).
>
> If st_value is the undefined symbol in executable is not zero, it
> is the PLT address in executable and ld.so will use it for function
> pointer which is different from the function address in shared
> library.

Ahh, I wasn't aware of that ELF detail.

Thanks,
Florian