[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20260921025615.GN23438@brightrain.aerifal.cx>
Date: Sun, 20 Sep 2026 22:56:16 -0400
From: Rich Felker <dalias@...c.org>
To: Khosro Moeini <khosro@...edu>
Cc: musl@...ts.openwall.com
Subject: Re: [PATCH v3] x86_64: add CET shadow stack support
On Sun, Sep 20, 2026 at 07:33:17PM +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.
> Unlike glibc, this implementation does not check environment variables.
> All the changes are guarded by SHSTK_ENABLED which is set through
> the --enable-cet configuration option.
>
> Signed-off-by: Khosro Moeini <khosro@...edu>
> ---
> >> Thanks for the feedback. Regarding the concerns discussed in the older
> >> thread:
> >>
> >> sigaltstack: The main program and its signal handlers use the same
> >> shadow stack, so there won't be resource problems. Please see:
> >> https://docs.kernel.org/next/x86/shstk.html#signal
> >
> > That is exactly the problem. It breaks the property that overflow of
> > the normal stack cannot prevent the signal handler from running.
>
> The size of the shadow stack is MIN(RLIMIT_STACK, 4 GB) and the shadow
> stack only stores return addresses. Given the 16-byte stack alignment
> in the x86_64 calling convention, in the extreme case where no extra
> stack space is used, the shadow stack would be half empty when the
> normal stack is overflowing. The Linux doc says:
> "Because the shadow stack stores only return addresses, a large shadow
> stack covers the condition that both the program stack and the signal
> alternate stack run out."
You mean there's RLIMIT_STACK committed for every thread?
Or is it not committed and crashes the process on OOM?
What happens if RLIMIT_STACK is small but the thread stack size
selected in the pthread_attr_t is large?
I have not seen any clear document addressing these kinds of concerns,
and at this point my tentative conclusion is that the people who made
this stuff and who are pushing this stuff don't care about any of
these considerations.
musl, OTOH, does.
> >> ucontext: removed from POSIX and not supported in musl
> >
> > That just means we don't presently have it in musl; distros are using
> > libucontext.
>
> This shouldn't be an issue. If the library supports shadow stack and
> has the shadow stack note, then shadow stack can be safely activated.
> If the library does not support shadow stack it wouldn't have the
> shadow stack note and thus shadow stack won't be activated for programs
> using this library.
So on a system built for shadow stack by default, would someone
building libuconext need to explicitly pass LDFLAGS to mark it not
compatible?
Also, it sounds like you are assuming "library" means .so; that is not
an assumption we make. Or are there .o level markings that would cause
the program to link without shadow stack?
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.
