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

[Jeff Xu]

On Tue, Dec 2, 2025 at 10:10 AM Florian Weimer <fweimer@redhat.com> wrote:
>
> * Stephen Röttger:
>
> > On Mon, Dec 1, 2025 at 2:46 PM Florian Weimer <fweimer@redhat.com> wrote:
> >>
> >> * Stephen Röttger:
> >>
> >> > Florian, do you see any other option to make this work?
> >>
> >> I don't think we can make this work due to the obvious conflict in
> >> goals.
> >>
> >> I'm not sure how many installations critically depend on glibc patching.
> >> It could be anti-cheats, tracing and debugging tools, userspace GPU
> >> drivers.  Anyone who has to rely on binary patching will have a very
> >> hard time upgrading to a newer glibc from their distribution because
> >> there is currently no reliable system-wide way to disable this
> >> functionality.
> >>
> >> Maybe it's not a problem because the number of impacted users is low?
> >> Hard to tell.
> >
> > Would it be an option to ship the feature disabled by default and enabling it
> > using a tunable instead?
> > That way, distros or applications could start using it and we would get some
> > confidence in the amount of incompatible code. And at that point, we could
> > switch the default to enabled.
>
> I think this would be a way forward.  It's how we handle SHSTK on x86-64
> today (and unfortunately there hasn't any progress moving beyond that
> stage).
>
Thanks, ChromeOS can work with this approach.

If glibc could add a configuration option
(--disable-memory-sealing-tunable) to "remove the tunable and enable
memory sealing by default," that would be even better. Distros like
ChromeOS that don't use live patching could build with this
configuration option. That can be optional or as a followup item
though.

Thanks and regards,
-Jeff

> Thanks,
> Florian
>