Re: [PATCH] core: Support heap-based trampolines

[Iain Sandoe <iain@sandoe.co.uk>]

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.

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?

Iain

** modulo the target maintainers implementing the builtins.