[PATCH v2 2/3] nptl: Add libc allocated shadow stack for new threads

[enh]

On Mon, Oct 6, 2025 at 9:38 AM Mark Brown <broonie@kernel.org> wrote:
>
> On Fri, Oct 03, 2025 at 03:55:13PM -0400, enh wrote:
> > On Thu, Oct 2, 2025 at 11:49 AM Mark Brown <broonie@kernel.org> wrote:
>
> > > At the minute when shadow stacks
> > > are enabled those signals will use the standard shadow stack together
> > > with the alternative normal stack.
>
> > which is probably fine?
>
> The kernel allocated shadow stacks are sized generously since currently
> userspace is unable to control their size so for practical use there
> should be little chance of them overflowing.

mildly off-topic, but has anyone thought about how java stack overflow
checking works with shadow stacks? iirc they [where for me "they" is
android's art; i don't know what openjdk does] mproect() their own
guard page just before the libc one. this lets them omit most stack
overflow checks, though even there they have some hackery to deal with
asan (and presumably hwasan; i don't think this is obsolete):

// We need larger stack overflow guards for ASAN, as the compiled code will have
// larger frame sizes. For simplicity, just use global
not-target-specific cflags.
// Note: We increase this for both debug and non-debug, as the overflow gap will
//       be compiled into managed code. We always preopt (and build
core images) with
//       the debug version. So make the gap consistent (and adjust for
the worst).
if len(ctx.Config().SanitizeDevice()) > 0 ||
len(ctx.Config().SanitizeHost()) > 0 {
cflags = append(cflags,
"-DART_STACK_OVERFLOW_GAP_arm=16384",
"-DART_STACK_OVERFLOW_GAP_arm64=16384",
"-DART_STACK_OVERFLOW_GAP_riscv64=16384",
"-DART_STACK_OVERFLOW_GAP_x86=16384",
"-DART_STACK_OVERFLOW_GAP_x86_64=20480")
} else {
cflags = append(cflags,
"-DART_STACK_OVERFLOW_GAP_arm=8192",
"-DART_STACK_OVERFLOW_GAP_arm64=8192",
"-DART_STACK_OVERFLOW_GAP_riscv64=8192",
"-DART_STACK_OVERFLOW_GAP_x86=8192",
"-DART_STACK_OVERFLOW_GAP_x86_64=8192")
}