[PATCH v2 1/3] elf: Add GNU_PROPERTY_MEMORY_SEAL gnu property

[Adhemerval Zanella Netto]

On 03/10/24 09:43, Adhemerval Zanella Netto wrote:
> 
> 
> On 01/10/24 03:45, Jan Beulich wrote:
>> On 30.09.2024 22:08, Adhemerval Zanella wrote:
>>> Along with -Wl,memory-seal/-Wl,nomemory-seal options to ld.bfd.
>>>
>>> The new attribute indicates that an ET_EXEC or ET_DYN ELF object should
>>> be memory-sealed if the loader supports it. Memory sealing is useful as
>>> a hardening mechanism to avoid either remapping the memory segments or
>>> changing the memory protection segments layout by the dynamic loader
>>> (for instance, the RELRO hardening). The Linux 6.10
>>> (8be7258aad44b5e25977a98db136f677fa6f4370) added the mseal syscall
>>> accomplishes it.
>>>
>>> A GNU property is used instead of a new dynamic section tag (like the
>>> one proposed for DT_GNU_FLAGS_1) because the memory sealing should be
>>> selectable for ET_EXEC and not only for ET_DYN. It also fits new opt-in
>>> security features like x86 CET or AArch64 BTI.
>>
>> What's wrong with DT_* in ET_EXEC type files? The first random executables
>> I looked at (as-new and ld-new) have a fair set of DT_*, so I don't see
>> why a note would need using instead. As per H.J.'s question, a note would
>> also pose a possible issue (as to how to deal with it) when found in an
>> object file.
> 
> I had the impression that this was not really required for ET_EXEC, but it
> seems I am wrong.  I will change to use a DT_FLAGS_1, similar to DF_GNU_1_UNIQUE.
> 
> 

In fact the main problem with DT_FLAGS_1 is it requires a dynamic section and
it might be tricky to get this with for non-pie static binaries (since a lot
of fields are mandatory).  We can just make it supported for PT_DYNAMIC, although
with GNU attribute it is easier to avoid this constraint.