From: Martin Uecker <ma.uecker@gmail.com>
To: Iain Sandoe <iain@sandoe.co.uk>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>,
FX Coudert <fxcoudert@gmail.com>,
Richard Biener <richard.guenther@gmail.com>,
Maxim Blinov <maxim.blinov@embecosm.com>,
Eric Botcazou <ebotcazou@adacore.com>,
Jeff Law <jeffreyalaw@gmail.com>,
aburgess@redhat.com
Subject: Re: [PATCH] core: Support heap-based trampolines
Date: Wed, 19 Jul 2023 12:43:11 +0200 [thread overview]
Message-ID: <521932ed3243a79ffe22ac3c9b6c2ae1f3ffa6ef.camel@gmail.com> (raw)
In-Reply-To: <81065A19-908D-438B-9C57-677674FE9146@sandoe.co.uk>
Am Mittwoch, dem 19.07.2023 um 10:29 +0100 schrieb Iain Sandoe:
> Hi Martin,
>
> > On 19 Jul 2023, at 10:04, Martin Uecker <ma.uecker@gmail.com>
> > wrote:
>
> > > > On 17 Jul 2023,
> > >
> >
> > > > > You mention setjmp/longjmp - on darwin and other platforms
> > > requiring
> > > > > non-stack based trampolines
> > > > > does the system runtime provide means to deal with this issue
> > > > > like
> > > an
> > > > > alternate allocation method
> > > > > or a way to register cleanup?
> > > >
> > > > There is an alternate mechanism relying on system libraries
> > > > that is
> > > possible on darwin specifically (I don’t know for other targets)
> > > but
> > > it will only work for signed binaries, and would require us to
> > > codesign everything produced by gcc. During development, it was
> > > deemed too big an ask and the current strategy was chosen (Iain
> > > can
> > > surely add more background on that if needed).
> > >
> > > I do not think that this solves the setjump/longjump issue -
> > > since
> > > there’s still a notional allocation that takes place (it’s just
> > > that
> > > the mechanism for determining permissions is different).
> > >
> > > It is also a big barrier for the general user - and prevents
> > > normal
> > > folks from distributing GCC - since codesigning requires an
> > > external
> > > certificate (i.e. I would really rather avoid it).
> > >
> > > > > Was there ever an attempt to provide a "generic" trampoline
> > > > > driven
> > > by
> > > > > a more complex descriptor?
> > >
> > > We did look at the “unused address bits” mechanism that Ada has
> > > used
> > > - but that is not really available to a non-private ABI (unless
> > > the
> > > system vendor agrees to change ABI to leave a bit spare) for the
> > > base
> > > arch either the bits are not there (e.g. X86) or reserved (e.g.
> > > AArch64).
> > >
> > > Andrew Burgess did the original work he might have comments on
> > > alternatives we tried
> > >
> >
> > For reference, I proposed a patch for this in 2018. It was not
> > accepted because minimum alignment for functions would increase
> > for some archs:
> >
> > https://gcc.gnu.org/legacy-ml/gcc-patches/2018-12/msg01532.html
>
> Right - that was the one we originally looked at and has the issue
> that it
> breaks ABI - and thus would need vendor by-in to alter as you say.
>
> > > > > (well, it could be a bytecode interpreter and the trampoline
> > > > > being
> > > > > bytecode on the stack?!)
> > > >
> > > > My own opinion is that executable stack should go away on all
> > > targets at some point, so a truly generic solution to the problem
> > > would be great.
> > >
> > > indeed it would.
>
> > I think we need a solution rather sooner than later on all archs.
>
> AFAICS the heap-based trampolines can work for any arch**, this
> issue is about
> system security policy, rather than arch, specifically?
>
> It seems to me that for any system security policy that permits JIT,
> (but not
> executable stack) the heap-based trampolines are viable.
I agree.
BTW; One option we discussed before, was to map a page with
pre-allocated trampolines, which look up the address of
a callee and the static chain in a table based on its own
address. Then no code generation is involved.
The difficult part is avoiding leaks with longjmp / setjmp.
One idea was to have a shadow stack consisting of the
pre-allocated trampolines, but this probably causes other
issues...
I wonder how difficult it is to have longjmp / setjmp walk
the stack in C? This would also be useful for C++
interoperability and to free heap-allocated VLAs.
As a user of nested functions, from my side it would also
ok to simply add a wide function pointer type that contains
address + static chain. This would require changing code,
but would also work with Clang's blocks and solve other
language interoperability problems, while avoiding all
existing ABI issues.
>
> This seems to be a useful step forward; and we can add some other
> mechanism to the flag’s supported list if someone develops one?
I think it is a useful step forward.
Martin
>
> Iain
>
> ** modulo the target maintainers implementing the builtins.
>
>
>
next prev parent reply other threads:[~2023-07-19 10:43 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-16 10:38 FX Coudert
2023-07-17 6:31 ` Richard Biener
2023-07-17 6:43 ` FX Coudert
2023-07-17 6:58 ` Iain Sandoe
2023-07-17 7:16 ` Iain Sandoe
2023-07-19 9:04 ` Martin Uecker
2023-07-19 9:29 ` Iain Sandoe
2023-07-19 10:43 ` Martin Uecker [this message]
2023-07-19 14:23 ` Iain Sandoe
2023-07-19 15:18 ` Martin Uecker
2023-08-05 14:20 ` FX Coudert
2023-08-20 9:43 ` FX Coudert
2023-09-06 15:44 ` FX Coudert
2023-09-14 10:18 ` Richard Biener
2023-09-16 19:10 ` Iain Sandoe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=521932ed3243a79ffe22ac3c9b6c2ae1f3ffa6ef.camel@gmail.com \
--to=ma.uecker@gmail.com \
--cc=aburgess@redhat.com \
--cc=ebotcazou@adacore.com \
--cc=fxcoudert@gmail.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=iain@sandoe.co.uk \
--cc=jeffreyalaw@gmail.com \
--cc=maxim.blinov@embecosm.com \
--cc=richard.guenther@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).