Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20260827192917.GQ23438@brightrain.aerifal.cx>
Date: Thu, 27 Aug 2026 15:29:18 -0400
From: Rich Felker <dalias@...c.org>
To: Khosro Moeini <khosro@...edu>
Cc: musl@...ts.openwall.com
Subject: Re: [PATCH] x86_64: add CET shadow stack support

On Mon, Aug 10, 2026 at 08:18:38PM +0000, Khosro Moeini wrote:
> Enable CET shadow stack on x86_64 when the executable and
> all loaded shared objects have the GNU_PROPERTY_X86_FEATURE_1_SHSTK bit set
> in their .note.gnu.property note. If shadow stack is enabled for a process,
> dlopen of an object without the shadow stack property note fails.

As mentioned on IRC, to begin with you should look into past threads
on this topic, such as:

https://www.openwall.com/lists/musl/2025/11/13/3

Getting anything along these lines accepted is going to have to
overcome considerations that have been blocking in the past.

Specific to your patch, putting arch-specific logic directly into
dynlink.c and other places, regardless of whether it's under #ifdef,
is not something that's going to be accepted. A baseline requirement
for an acceptable version of arch-specific loader behavior is
abstracting it so that the code in dynlink.c and any other common
files is shared across archs, with any arch-specific implementation
details for that provided by a file in the arch-specific directory.

In general, a proposal like this also needs to explain ABI
considerations and what the compatibility properties in a mixed
ecosystem not entirely using the feature would be.

Finally, for any new contributions that were developed outside of
visibility of people already working on the project, we are going to
need a declaration that no AI was used in the production of the code.
I would like to just be able to assume that's the default, but there
have been enough cases where there have been doubts that we really
just need this stated clearly upfront rather than stewing in
suspicion. This is not anything specific to your patch but something
I've been meaning to write up in more detail to publish on the
website, and I'm just bringing it up in the context of your patch
because it's the first patch we've had in a while that's not a small
and localized change.

Rich

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.