Re: [ld] Allow custom sections to be under PT_GNU_RELRO

[Cary Coutant]

> > https://lists.llvm.org/pipermail/llvm-dev/2020-March/140395.html
> >
> > I understand the reason of having these conventions in linkers. On the
> > other hand, there already exists a format with the fixed ".rel.ro"
> > suffix for .data and .bss. Custom suffixes would also mean that the user
> > code would depend more on implementation-specific things, i.e. prefixes.
> > For example, one would wonder, should they annotate their data with
> > __attribute__((section(...))) for ".data.rel.ro.my_section" or
> > ".bss.rel.ro.my_section"?
> >
> > What do you think of the magic ".rel.ro" idea?
>
> We could sacrifice a section flag for this. The feature may be
> sufficiently important for that.

My first reaction was: Do you *really* need to use a new custom
section name? But after reading through the thread on the LLVM list, I
see why -- you want the RTTI-like sections to be contiguous within the
RELRO segment.

The gold sources have this comment:

// With -z relro, we have to recognize the special sections by name.
// There is no other way.

String matching on the section name is ugly and a performance hit
whether it's a fixed section name (as it is now), a prefix, or a
suffix. Yes, it should have been done with a flag from the beginning.

Theoretically, we might not even have needed a new flag. If the
compiler would mark RELRO sections as read-only, the linker could look
for read-only, non-executable sections with dynamic relocations, and
mark them as RELRO, or simply turn on SHF_WRITE for -z norelro. But
that would break under older linkers, so it was much better from a
compatibility standpoint to mark RELRO sections as writable, meaning
there has to be some other way of recognizing that they're really
read-only but for the relocations. It may also have made things
difficult for the linker, requiring a scan over the relocations before
deciding where to place the section (I haven't looked carefully to see
if that would be a problem in gold).

Starting from where we are now, I'd say we need an SHF_RELRO flag, and
compilers should start setting that flag on .data.rel.ro and
.data.rel.ro.local sections. Linkers should treat all .data.rel.ro and
.data.rel.ro.local sections as if the flag were set, regardless. Maybe
in 10-20 years, we can finally take those strcmp's out.

Any sections marked SHF_RELRO should also be marked SHF_WRITE, for
compatibility with older linkers and to make it simpler to ignore the
flag in the -z norelro case. I'd probably also want to require that
they NOT be SHF_EXECINSTR.

That probably also means that we should graduate PT_GNU_RELRO to the
gABI level, as PT_RELRO. Or, alternatively, DT_RELRO and DT_RELROSZ
entries in the dynamic table. (I kind of prefer the dynamic table over
the program header table for things like this, since it's the dynamic
linker, not the kernel loader, that needs to know about it.)

-cary

[Ali Bahrami]

On 4/6/20 6:28 PM, Cary Coutant wrote:
> That probably also means that we should graduate PT_GNU_RELRO to the
> gABI level, as PT_RELRO.

Is RELRO really universal? We don't use it on Solaris
(multiple reasons, not really important), and I'm not aware
of any plans to adopt it. If we're an outlier, so be it, but
otherwise, I'd vote to keep it in the GNU OSABI.

> Or, alternatively, DT_RELRO and DT_RELROSZ
> entries in the dynamic table. (I kind of prefer the dynamic table over
> the program header table for things like this, since it's the dynamic
> linker, not the kernel loader, that needs to know about it.)

I agree with this. There's no reason for something that the dynamic
loader interprets to be a program header, rather than a dynamic
table entry. (Maybe DT_GNU_RELRO and DT_GNU_RELROSZ, as per the above).

Thanks.

- Ali

[Suprateeka R Hegde]

On 07-Apr-2020 07:44 am, Ali Bahrami wrote:
> On 4/6/20 6:28 PM, Cary Coutant wrote:
>> That probably also means that we should graduate PT_GNU_RELRO to the
>> gABI level, as PT_RELRO.
>
>    Is RELRO really universal?

No.

> We don't use it on Solaris
> (multiple reasons, not really important), and I'm not aware
> of any plans to adopt it.

Was not of much use when I checked the need for this on our platform, HP-UX.

However, I had implemented a simplified version of this, using a simple
mprotect(2) on PLT pages, after immediate bindings. I did this just to
ease the debug-ability when certain set of apps were inadvertently
writing past their data boundaries and corrupting the PLT.

> If we're an outlier, so be it, but
> otherwise, I'd vote to keep it in the GNU OSABI.

We are OK as long as it is optional. However, I do prefer it under GNU

OSABI.

>> Or, alternatively, DT_RELRO and DT_RELROSZ
>> entries in the dynamic table. (I kind of prefer the dynamic table over
>> the program header table for things like this, since it's the dynamic
>> linker, not the kernel loader, that needs to know about it.)
>
> I agree with this. There's no reason for something that the dynamic
> loader interprets to be a program header, rather than a dynamic
> table entry. (Maybe DT_GNU_RELRO and DT_GNU_RELROSZ, as per the above).

Yes, makes sense.

--
Supra

[Cary Coutant]

> >> That probably also means that we should graduate PT_GNU_RELRO to the
> >> gABI level, as PT_RELRO.
> >
> > Is RELRO really universal?
>
> No.

While it may not be in use on all platforms, it strikes me as
certainly useful in general.

> > We don't use it on Solaris
> > (multiple reasons, not really important), and I'm not aware
> > of any plans to adopt it.
>
> Was not of much use when I checked the need for this on our platform, HP-UX.
>
> However, I had implemented a simplified version of this, using a simple
> mprotect(2) on PLT pages, after immediate bindings. I did this just to
> ease the debug-ability when certain set of apps were inadvertently
> writing past their data boundaries and corrupting the PLT.

I recall designing something similar for HP-UX, though I can't
remember the details, and I can't find any evidence in the published
ELF documents. It's possible we merely discussed the idea internally
but never implemented it. I think we called it something like
"relocatable constants."

-cary

[Cary Coutant]

> >That probably also means that we should graduate PT_GNU_RELRO to the
> >gABI level, as PT_RELRO. Or, alternatively, DT_RELRO and DT_RELROSZ
> >entries in the dynamic table. (I kind of prefer the dynamic table over
> >the program header table for things like this, since it's the dynamic
> >linker, not the kernel loader, that needs to know about it.)
>

> I can foresee people's objection to depriving one value 0x6474e552 from
> the PT_LOOS~PT_HIOS range. (See a recent discussion
> https://groups.google.com/forum/#!msg/x86-64-abi/7sr4E6THl3g/zUU2UPHOAQAJ "RFC: Usefulness of SHT_X86_64_UNWIND")

I didn't mean to imply using the existing PT_GNU_RELRO value. Of
course I'd assign a new value in the gABI range. But this is moot, as
it seems the consensus is that RELRO should remain a GNU extension.

-cary

[James Henderson]

On Tue, 7 Apr 2020 at 17:24, Cary Coutant <ccou...@gmail.com> wrote:

> >> That probably also means that we should graduate PT_GNU_RELRO to the
> >> gABI level, as PT_RELRO.
> >
> >    Is RELRO really universal?
>
> No.

While it may not be in use on all platforms, it strikes me as
certainly useful in general.

FWIW, I work in an LLVM-based toolchain, using clang and LLD, and we use PT_GNU_RELRO in a non-GNU environment with a custom loader. I'm not sure at what point something stops being a "GNU" extension, when other non-GNU toolchains start adopting it, but certainly we do find it useful.

 

> > We don't use it on Solaris
> > (multiple reasons, not really important), and I'm not aware
> > of any plans to adopt it.
>
> Was not of much use when I checked the need for this on our platform, HP-UX.
>
> However, I had implemented a simplified version of this, using a simple
> mprotect(2) on PLT pages, after immediate bindings. I did this just to
> ease the debug-ability when certain set of apps were inadvertently
> writing past their data boundaries and corrupting the PLT.

I recall designing something similar for HP-UX, though I can't
remember the details, and I can't find any evidence in the published
ELF documents. It's possible we merely discussed the idea internally
but never implemented it. I think we called it something like
"relocatable constants."

-cary

--
You received this message because you are subscribed to the Google Groups "Generic System V Application Binary Interface" group.
To unsubscribe from this group and stop receiving emails from it, send an email to generic-abi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/generic-abi/CAJimCsEunNAB-SL4%3DRmBWmESTwP%2BhPSF96jH5wmLzjacHC%2BDow%40mail.gmail.com.

[Carlos O'Donell]

On 4/8/20 3:36 AM, James Henderson wrote:
> On Tue, 7 Apr 2020 at 17:24, Cary Coutant <ccou...@gmail.com> wrote:
>
>>>>> That probably also means that we should graduate PT_GNU_RELRO to the
>>>>> gABI level, as PT_RELRO.
>>>>
>>>> Is RELRO really universal?
>>>
>>> No.
>>
>> While it may not be in use on all platforms, it strikes me as
>> certainly useful in general.
>>
>
> FWIW, I work in an LLVM-based toolchain, using clang and LLD, and we use
> PT_GNU_RELRO in a non-GNU environment with a custom loader. I'm not sure at
> what point something stops being a "GNU" extension, when other non-GNU
> toolchains start adopting it, but certainly we do find it useful.

That is certainly a data point in favour of PT_RELRO.

It stops being an OS ABI-specific value when we decide on this list that
there is consensus and a solid design to put it into the gABI in a way
that works for all the interested parties and their toolchains.

Until that time it's an extension of the gABI as defined by the OS ABI
and hopefully documented somewhere.

If the ELF files your toolchain generates use a particular OS ABI, and that
OS ABI has documented semantics for certain OS ABI-specific PT_* values
and you follow those semantics, that's great.

If instead you are using the OS ABI because it's convenient starting point
for modifying a toolchain, that's also fine, but at this point you are
somewhere between the existing ABI and some new ABI that hasn't been
properly assigned an OS ABI (or perhaps just ELFOSABI_STANDALONE).

A benefit of moving designs into the gABI is that you can avoid having
to redefine the values for your particular OS ABI.

--
Cheers,
Carlos.

[Konstantin Belousov]

On Wed, Apr 08, 2020 at 08:36:26AM +0100, James Henderson wrote:
> On Tue, 7 Apr 2020 at 17:24, Cary Coutant <ccou...@gmail.com> wrote:
>
> > > >> That probably also means that we should graduate PT_GNU_RELRO to the
> > > >> gABI level, as PT_RELRO.
> > > >
> > > > Is RELRO really universal?
> > >
> > > No.
> >
> > While it may not be in use on all platforms, it strikes me as
> > certainly useful in general.
> >
>
> FWIW, I work in an LLVM-based toolchain, using clang and LLD, and we use
> PT_GNU_RELRO in a non-GNU environment with a custom loader. I'm not sure at
> what point something stops being a "GNU" extension, when other non-GNU
> toolchains start adopting it, but certainly we do find it useful.
>

PT_GNU_RELRO is supported by the FreeBSD dynamic linker, for instance.
I think other BSDs support it as well.