[PATCH v8 0/8] Add support for memory sealing

[Adhemerval Zanella Netto]

On 03/02/25 16:40, Florian Weimer wrote:
> * Adhemerval Zanella Netto:
> 
>>> CRIU needs to be able to unmap everything that was initially loaded by
>>> the kernel and glibc.  This will stop working if we use mseal for glibc
>>> itself.
>>
>> So in this case the easiest way it to filter of mseal (with seccomp or
>> something related) and disable sealing.  I don't have a easy solution.
> 
> Please test with CRIU and trace and find a way to make them work again
> if they are broken.

I don't see a way to make CRIU work where it is orthogonal of the idea of
immutability of memory sealing.  But I don't have much knowledge of how CRIU
work internally, maybe someone more well versed in this project could help us
out here.

> 
>>>> A dynamic tag would add support only for ET_DYN, where a GNU attribute
>>>> allows for ET_EXEC as well (similar to recent hardening mechanism like
>>>> BTI, GCS, etc.).
>>>
>>> We don't need the compatibility indicator on static executables because
>>> incompatible static binaries won't have the PT_* header that requests
>>> sealing.
>>
>> But we will still need to mark the ET_EXEC as opt-in for sealing.  A dynamic
>> tag will be only enabled for ET_DYN.
> 
> If the PT_* address ranges are present, the binary opts in to sealing.

But you still need a opt-in mark to be memory sealed, that's the gnu attribute
marking.  A dynamic tag would not be present on ET_EXEC (although with PIE
being more common it might not be that common), so we still need something
else to mark the binary as opt-in to memory sealing.

> 
>> Is this allocated dynamic during process execution of defined during build?
>> Can't you put this on relro segment, with a constructor to do any required
>> initialization?
> 
> Constructors currently run after RELRO has been applied.

Right, so is this some metadata in .data that is initialized after or during
process execution?  If so, I think for this case it would be better to have
something like a special section, like ".gnu.mseal"; where the idea of
adding sealing range makes sense.  But again, I think this is different
proposal and not really a blocker for this hardening.