[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20260311182929.GP3520958@port70.net>
Date: Wed, 11 Mar 2026 19:29:29 +0100
From: Szabolcs Nagy <nsz@...t70.net>
To: James Y Knight <jyknight@...gle.com>
Cc: Rich Felker <dalias@...c.org>, musl@...ts.openwall.com,
Thorsten Glaser <tg@...bsd.de>
Subject: Re: Question about flexible array
* James Y Knight <jyknight@...gle.com> [2026-03-11 13:33:44 -0400]:
> On Wed, Mar 11, 2026 at 12:51 PM Szabolcs Nagy <nsz@...t70.net> wrote:
> >
> > the layout of ucontext passed by the kernel to
> > signal handlers and the *context functions in
> > userspace are already different on other targets
> > (i know this for sure on aarch64, but i don't
> > think that was the first to do this),
> > i.e. passing kernel ucontext to a setcontext
> > function is invalid.
>
> Ah, ok!
>
> I didn't realize this usage was already broken (at least on some
> architectures, if not all). I have never tried to do it myself, nor do
> I know of any reason why someone would want to, but it is actually
> _documented_ to work, per "man setcontext":
> "The context should have been obtained by a call of getcontext(), or
> makecontext(3), or received as the third argument to a signal handler
> (see the discussion of the SA_SIGINFO flag in sigaction(2))."
>
> If it's been broken for aarch64 for a long time (has it been since
> aarch64 was added? Or is this recent breakage?), presumably that would
> indicate that there's no real-world usage of setcontext/swapcontext on
> a kernel-provided ucontext_t...And if that's the case, it's
> _extremely_ unfortunate that these functions were defined to use the
> same struct as the one provided to a signal handler in the first place
> -- they really ought to be using something a lot closer to (if not
> exactly) jmp_buf, instead.
turns out i actually fixed the layout for aarch64
https://sourceware.org/cgit/glibc/commit/?id=2b1d7148e3664eeb177ae2fc91bf282d75da7623
but not the async-sync incompat which also affects
x86_64, sparc, hppa, sh, ia64, m68k, s390, arm
according to
https://sourceware.org/legacy-ml/libc-alpha/2014-04/msg00006.html
the async-sync incompat is simply that setcontext
will only restore the sync (callee saved) regs, not
all regs (needed for an async interrupt) and the only
way to fix that is via a syscall (since there can
be extensions only the kernel knows about).
since the layout matches, code can inspect callee
saved state independently of kernel vs user context.
but passing kernel context to user *context funcs
won't work. but i would still expect incompat layout
to work in practice too (only arch specific code
looks at these fields and they generally know if the
struct is async or sync, so worst-case is ugly arch
specific code dealing with ucontext).
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.
