Re: [llvm-dev] RFC: Add GNU_PROPERTY_UINT32_AND_XXX/GNU_PROPERTY_UINT32_OR_XXX

["Fāng-ruì Sòng" <maskray@google.com>]

On Thu, Jun 17, 2021 at 5:24 PM H.J. Lu <hjl.tools@gmail.com> wrote:
>
> On Thu, Jun 17, 2021 at 5:06 PM Fāng-ruì Sòng <maskray@google.com> wrote:
> >
> > On 2021-06-17, H.J. Lu wrote:
> > >On Thu, Jun 17, 2021 at 1:25 PM Fāng-ruì Sòng <maskray@google.com> wrote:
> > >>
> > >> On Thu, Jun 17, 2021 at 12:46 PM H.J. Lu <hjl.tools@gmail.com> wrote:
> > >> >
> > >> > On Thu, Jun 17, 2021 at 12:38 PM Fangrui Song <maskray@google.com> wrote:
> > >> > >
> > >> > > On 2021-06-17, H.J. Lu via llvm-dev wrote:
> > >> > > >On Thu, Jan 21, 2021 at 7:02 AM H.J. Lu <hjl.tools@gmail.com> wrote:
> > >> > > >>
> > >> > > >> On Wed, Jan 13, 2021 at 9:06 AM H.J. Lu <hjl.tools@gmail.com> wrote:
> > >> > > >> >
> > >> > > >> > 1. GNU_PROPERTY_UINT32_AND_LO..GNU_PROPERTY_UINT32_AND_HI
> > >> > > >> >
> > >> > > >> >  #define GNU_PROPERTY_UINT32_AND_LO 0xb0000000
> > >> > > >> >  #define GNU_PROPERTY_UINT32_AND_HI 0xb0007fff
> > >> > > >> >
> > >> > > >> > A bit in the output pr_data field is set only if it is set in all
> > >> > > >> > relocatable input pr_data fields.  If all bits in the the output
> > >> > > >> > pr_data field are zero, this property should be removed from output.
> > >> > > >> >
> > >> > > >> > If the bit is 1, all input relocatables have the feature.  If the
> > >> > > >> > bit is 0 or the property is missing, the info is unknown.
> > >> > >
> > >> > > How to use AND in practice?
> > >> > > Are you going to add .note.gnu.property to all of crt1.o crti.o
> > >> > > crtbegin.o crtend.o crtn.o and miscellaneous libc_nonshared.a object
> > >> > > files written in assembly?
> > >> > >
> > >> > > >> > 2. GNU_PROPERTY_UINT32_OR_LO..GNU_PROPERTY_UINT32_OR_HI
> > >> > > >> >
> > >> > > >> >  #define GNU_PROPERTY_UINT32_OR_LO 0xb0008000
> > >> > > >> >  #define GNU_PROPERTY_UINT32_OR_HI 0xb000ffff
> > >> > > >> >
> > >> > > >> > A bit in the output pr_data field is set if it is set in any
> > >> > > >> > relocatable input pr_data fields. If all bits in the the output
> > >> > > >> > pr_data field are zero, this property should be removed from output.
> > >> > > >> >
> > >> > > >> > If the bit is 1, some input relocatables have the feature.  If the
> > >> > > >> > bit is 0 or the property is missing, the info is unknown.
> > >> > > >> >
> > >> > > >> > The PDF is at
> > >> > > >> >
> > >> > > >> > https://gitlab.com/x86-psABIs/Linux-ABI/-/wikis/uploads/0690db0a3b7e5d8a44e0271a4be54aa7/linux-gABI-and-or-2021-01-13.pdf
> > >> > > >> >
> > >> > > >> > --
> > >> > > >> > H.J.
> > >> > > >>
> > >> > > >> Here is the binutils patch to implement it.
> > >> > > >>
> > >> > > >
> > >> > > >If there are no objections, I will check it in tomorrow.
> > >> > >
> > >> > > If the use case is just ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA, it'd be
> > >> > > very kind of you if you can collect more use cases before generalizing
> > >> > > this into a non-arch-specific GNU PROPERTY.
> > >> > >
> > >> > > The "copy relocations on protected data symbols" thing is x86 specific
> > >> > > and only applies with gcc+GNU ld+glibc.
> > >> > > Non-x86 architectures don't have this thing.
> > >> > > gold doesn't have this thing.
> > >> > > clang doesn't have this thing.
> > >> >
> > >> > It will be used to remove copy relocation and implement canonical function
> > >> > pointers, which will benefit protected data and function.
> > >>
> > >> The action items in
> > >> https://gitlab.com/x86-psABIs/x86-64-ABI/-/issues/8#note_593822281
> > >> can be applied without a GNU PROPERTY.
> > >>
> > >> If we want to enforce the link-time check that a shared object is no longer
> > >> compatible with copy relocations, just make the shared object's non-weak
> > >> definitions protected, and add a GNU ld diagnostic like gold
> > >> (https://sourceware.org/bugzilla/show_bug.cgi?id=19823)
> > >>
> > >> ---
> > >>
> > >> For functions,
> > >>
> > >> On x86-64, gcc -fpic has been using  leaq    addr()(%rip), %rax since at least
> > >> 4.1.2 (oldest gcc I can find on godbolt):
> > >>
> > >>   __attribute__((visibility("protected")))
> > >>   void *addr() { return (void*)addr; }
> > >>
> > >>   // a protected non-definition declaration is the same.
> > >>
> > >>   // while asm(".protected addr") can use GOT, it is super rare if ever exists
> > >>   // outside glibc elf/vis*.c
> > >>
> > >> I have checked all of binutils 2.11, 2.16, 2.20, 2.24, 2.35. The have
> > >> the same diagnostic:
> > >>
> > >>   relocation R_X86_64_PC32 against protected function `addr' can not
> > >> be used when making a shared object
> > >>
> > >> I think we can assert that taking the address of a protected function
> > >> never works with GNU ld.
> > >> So no compatibility concern.
> > >> Fixing it (https://sourceware.org/pipermail/binutils/2021-June/116985.html)
> > >> doesn't need any GNU PROPERTY.
> > >>
> > >> ---
> > >>
> > >> For variables, if an object file/archive member does not have GNU PROPERTY, do
> > >> you consider it incompatible with "single global definition"? That is why I
> > >> mentioned crt1.o crti.o crtbegin.o crtend.o crtn.o and libc_nonshared.a members
> > >> written in assembly.
> > >>
> > >> If you consider such an object compatible with "single global definition", I
> > >> don't see why a GNU PROPERTY is needed.
> > >>
> > >> If you consider such an object incompatible with "single global definition", I
> > >> don't see how "single global definition" benefits can be claimed giving so many
> > >> prebuilt object files without GNU PROPERTY.
> > >
> > >Please see the slides in
> > >
> > >https://gitlab.com/x86-psABIs/x86-64-ABI/-/issues/8
> > >
> > >which includes
> > >
> > >Dynamic Linker for Single Global Definition
> > >• Check the single global definition marker on all components, the executable
> > >and its dependency shared libraries.
> > >• Issue an error/warning if the marker is not consistent on all components.
> >
> > This is not appealing from a compatibility point of view.
> > It is common that a system has mixed shared objects:
> >
> > -fsingle-global-definition => a.so (marker value 1)
> > no -fsingle-global-definition => b.so (marker value 0 or no marker)
> > Issuing a warning will be annoying.
> >
>
> I updated my proposal to
>
> Dynamic Linker for Single Global Definition
> • Check the single global definition marker on all components, the executable
> and its dependency shared libraries.

I find that I forgot (in so many of my previous messages) to mention
that the name "single global definition" may give a false impression.
For example, a dynamic STV_DEFAULT STB_WEAK/STB_GLOBAL symbol defined
in a shared object can still be interposed.

> • Disallow copy relocation against definition with the STV_PROTECTED
> visibility in the shared library with the marker.

If this is for GNU ld x86 only, I'm fine with it:)

gold and ld.lld just emit an error unconditionally. I think non-x86
GNU ld ports which never support "copy relocations on protected data
symbols" may want to make the diagnostic unconditional as well.
Well, while (Michael Matz and ) I think compatibility check for "copy
relocations on protected data symbols" is over-engineering (and
Alan/Cary think it was a mistake), if you still want to add it, it is
fine for me...
For Clang, I hope we will not emit such a property, because Clang
never supports the "copy relocations on protected data symbols"
scheme.

> • For systems without function descriptor:
> • Disallow non-GOT function pointer reference in executable without
> the marker to the
> definition with the STV_PROTECTED visibility in a shared library with
> the marker.

I think this can be unconditional, because the "pointer equality for
STV_PROTECTED function address in -shared" case hasn't been working
for GNU ld for at least 20 years...
Many ports don't even produce a dynamic relocation.
I don't mind if you add it just for symmetry, but it just feels unneeded.

> • Use the address of the function body as function pointer on functions with the
> STV_PROTECTED visibility, which are defined in shared libraries with the marker.


>
> --
> H.J.