Flag for late RELRO application

[Carlos O'Donell]

On 06/11/2018 01:37 PM, Florian Weimer wrote:
> On 06/11/2018 06:29 PM, Carlos O'Donell wrote:
>> If you have to markup existing code with
>> attributes to get this to work, you might as well collect them
>> into a special section and use a 'late RELRO' flag for it,
>> extending the existing RELRO framework.
> 
> Again, is this really worth the complexity?

Consider the behaviour the flag will enable.

Say it becomes wildly successful, and all application authors turn
it on. Now, everyone is using "LATE" (flag) + "RELRO." Maybe even
against your recommendations.

If we wish to further harden such binaries (applying some of RELRO 
earlier again), would we have a way to do so easily?

Do we have to define the "late RELRO" flag in such a way as to guide
implementations to make choices that allow them to continue to be
able to incrementally harden applications?

For example:

DT_FLAGS:

* DF_LATE_RELRO flag set in DT_FLAGS if the dynamic loader should
  run all constructors and initializers before marking all relocations
  read-only.

Special Sections:

* ".data.re.ro.late" - SHT_PROGBITS, SHF_ALLOC+SHF_WRITE
  This section holds data that must be writable until after all
  constructors and initializers have been run.

Implementation considerations:

* The guidance to linker implementations is that DF_LATE_RELRO should
  only be set if an input section contained data in the section
  ".data.rel.ro.late" to disambiguate the data that really needs the
  late RELRO semantics from those that don't. So we can eventually
  harden in two stages. For now the linker can choose to merge everything
  together and let the dynamic loader delay RELRO.

In this way we define the flag, *and* a section for late RELRO in such
a way that we can find these uses later if we want to move them or further
harden such binaries. This is a bit more work, but I think it will pay
dividends if we ever need to do further hardening.

Thoughts?

Cheers,
Carlos.