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

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

Hi Martin,

> On 19 Jul 2023, at 11:43, Martin Uecker via Gcc-patches <gcc-patches@gcc.gnu.org> wrote:
> 
> Am Mittwoch, dem 19.07.2023 um 10:29 +0100 schrieb Iain Sandoe:

>>> 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?

>>>>> 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.

That reads similar to the scheme Apple have implemented for libobjc and libffi.
In order to be extensible (i.e to allow the table to grow at runtime), it means
having some loadable executable object; if that is implemented in a way shared
between users (delivered as part of the implementation) then, for Darwin at
least, it must be codesigned - which is somewhere I really want to avoid going
with GCC.  

> 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...

With a per-thread table, I *think* for most targets, we discussed in the team
maintaining a ’tide mark’ of the stack as part of the saved data in the
trampoline (not used as part of the execution, but only as part of the allocation
mangement)… but ..

> 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.

… this would be a better solution (as we can see trampolines are a small
leak c.f. the general uses)?

> 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.

How does that work when passing a callback to libc (e.g. qsort?)

(Implementing Clang’s blocks is also on my TODO, but a different discussion ;))

>> 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.

Assembled maintainers, do you think this is OK for trunk given the various
discussions above?

thanks
Iain