[PATCH v6 0/9] Add support for memory sealing

[Stephen Röttger]

On Mon, Oct 13, 2025 at 5:08 PM Adhemerval Zanella Netto
<adhemerval.zanella@linaro.org> wrote:
>
>
>
> On 13/10/25 12:00, Florian Weimer wrote:
> > * Adhemerval Zanella Netto:
> >
> >>>> There are two solutions for such a case in the future:
> >>>> 1. Do not turn on sealing when building the main binary.
> >>>> 2. Use the .gnu.mutable solution to mark specific areas/variables to
> >>>> be not sealable.
> >>>
> >>> (1) does not work if we are dealing with code that is usually loaded
> >>> through dlopen (such as userspace graphics drivers and Python modules).
> >>>
> >>> (2) does not really apply here because this would have to be done during
> >>> the glibc build.
> >>
> >> This (2) can be done at glibc build to make _dl_debug_update mutable, and
> >> that's the idea of adding the mutable.
> >
> > We only learned about _dl_debug_update because of the patching failure.
> > There are probably other examples.  And I'm not sure if using GCC's
> > section attribute is sufficient to achieve suitable placement of all the
> > functions we know about—so we might have to write more functions in
> > assembler for predictable outcomes.
>
> The underlying question is whether this patching is really required and
> expected. But I think we make an opt-out libc sealing with a tunable if the
> bianry requires such patching; this enable make it the default.

Code patching glibc functions (and other code) is exactly what this feature
tries to prevent. So, the only way I see to support this would be to opt-out at
compile time or process startup time using a glibc tunable.

> 2. Use the .gnu.mutable solution to mark specific areas/variables to
> be not sealable.
I don't think this should be usable for code. If we apply it to a
glibc function,
it will defeat the purpose of memory sealing.
For a dlopen'ed library, I think the tunable is the best solution.

Florian, do you see any other option to make this work?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5283 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20251201/3697b727/attachment.p7s>