[llvm-dev] [lld] RFC: Allow custom sections to be under GNU_RELRO

[Peter Smith via llvm-dev]

Hello Anton,

> At the moment, all big 3 ELF linkers hardcode names of read-only-after-relocation sections (.data.rel.ro, .bss.rel.ro, .ctors, .eh_frame, ...). We would
> like to propose extending this for custom sections that end with ".rel.ro".
>
> What do you think? Would this be useful to you?

In principle, if you can get a convention agreed by the ELF linkers then I don't see too much of a problem. There are two places I can see where you may get some push back.

The first is the use of a custom suffix, all other linker conventions, that I know of, use prefixes as these are much easier and faster to match against names. This can be important in large programs compiled -ffunction-sections as there can be millions of sections to match.

The second is that you may be able to accomplish what you need with a linker script, I'm guessing you don't want to use the existing .data.rel.ro.* convention to take advantage of linker generated symbols. The following example (not tested) assumes a naming convention of .data.rel.ro.RTTI.* in your program.

  .data.rel.ro : {
                        PROVIDE_HIDDEN (__RTTI_start = .); *(.data.rel.ro.RTTI.*) ; PROVIDE_HIDDEN (__RTTI_end = .);
                        *(.data.rel.ro.local* .gnu.linkonce.d.rel.ro.local.*) *(.data.rel.ro .data.rel.ro.* .gnu.linkonce.d.rel.ro.*) }

This would have your table contiguous in the .data.rel.ro OutputSection and can be found with the __RTTI_start and __RTTI_end symbols. It may not work so well if you are using SHF_LINK_ORDER for the RTTI sections as some linkers tend to handle these better when every InputSection in the OutputSection has SHF_LINK_ORDER.

Peter


________________________________________
From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Anton Bikineev via llvm-dev <llvm-dev at lists.llvm.org>
Sent: 26 March 2020 19:46
To: llvm-dev at lists.llvm.org
Subject: [llvm-dev] [lld] RFC: Allow custom sections to be under GNU_RELRO

Hey,

We would like to propose an idea that would help security harden applications that define custom sections.

Motivation and Background
In Chromium we have a garbage collector that implements some RTTI machinery in the form of a table. This table is used by the collector to trace and finalize garbage collected objects. We're thinking of using __attribute__((section(...))) so that the table can be created and merged at link time. We also use -fPIC and therefore rely on the dynamic linker to process relocations in this table after the program is loaded. At the same time, we want the table to be read-only after relocations are applied, in the same fashion as e.g. .got sections are write protected after eager binding (with -z,relro,-z,now). The custom section can't be mprotected, because it can live in the same PT_LOAD segment as other modifiable data (e.g. .data).

At the moment, all big 3 ELF linkers hardcode names of read-only-after-relocation sections (.data.rel.ro<http://data.rel.ro>, .bss.rel.ro<http://bss.rel.ro>, .ctors, .eh_frame, ...). We would like to propose extending this for custom sections that end with ".rel.ro<http://rel.ro>".

What do you think? Would this be useful to you?

--
Sincerely,
Anton.