Re: Flag for late RELRO application

[Florian Weimer <fweimer@redhat.com>]

On 06/11/2018 06:29 PM, Carlos O'Donell wrote:
> On 06/11/2018 07:23 AM, Florian Weimer wrote:
>> I would like to add a flag to gABI (visible in the dynamic section)
>> which indicates that the loader shall apply RELRO protection only
>> after running the ELF constructors from DT_INIT and DT_INIT_ARRAY.
> 
> I assume that means also after DT_PREINIT_ARRAY?

Yes, that too.

> Should the semantics be worded in such a way as to simply say that
> all constructors have finished running?

That would be okay.

> That could be a lot of code running without RELRO protections.

Hence I suggest to require opt-in via a flag.

>> This would allow applications to allocate a mapping and store a
>> pointer to it in permanently read-only memory.  On the mapping
>> itself, the application can set the protection flags (and keys) as
>> needed.
> 
> Wouldn't it be safer to have some kind of second "type" of RELRO
> for these particular uses?

Safer in what sense?  It's going to be quite complicated (new DT_* 
entries, linker support for various sections, documentation for the new 
section names).

A new flag would only need very limited linker support, and we'd have to 
document the existing section names (which are already part of the ABI, 
but may not be documented).

> This way we don't mix what is effectively early RELRO with late
> RELRO?

I'm not convinced the additional complexity is worth it.  It's possible 
to write a shared object in such a way that constructors are minimized 
(and we should clean up the ones automatically provided by GCC, 
independently of that).  If necessary, a separate object can be used.

> I know that it's easier to just defer RELRO (all the existing
> machinery is already in place for it), but I'm wondering if that
> won't worsen the protection in substantial ways.
> 
> For example how would an application mark a pointer as read-only
> but also write to it?

This seems to be portable across all GNU architectures:

void *ptr __attribute__ ((section (".data.rel.ro")));

> 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?

Thanks,
Florian