From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp001-out.apm-internet.net (smtp001-out.apm-internet.net [85.119.248.222]) by sourceware.org (Postfix) with ESMTPS id 06E0F38582A1 for ; Wed, 19 Jul 2023 14:23:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 06E0F38582A1 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=sandoe.co.uk Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=sandoe.co.uk Received: (qmail 73293 invoked from network); 19 Jul 2023 14:23:24 -0000 X-APM-Out-ID: 16897766047329 X-APM-Authkey: 257869/1(257869/1) 17 Received: from unknown (HELO smtpclient.apple) (81.138.1.83) by smtp001.apm-internet.net with SMTP; 19 Jul 2023 14:23:24 -0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.3\)) Subject: Re: [PATCH] core: Support heap-based trampolines From: Iain Sandoe In-Reply-To: <521932ed3243a79ffe22ac3c9b6c2ae1f3ffa6ef.camel@gmail.com> Date: Wed, 19 Jul 2023 15:23:23 +0100 Cc: GCC Patches , FX Coudert , Richard Biener , Maxim Blinov , Eric Botcazou , Jeff Law , aburgess@redhat.com Content-Transfer-Encoding: quoted-printable Message-Id: References: <81065A19-908D-438B-9C57-677674FE9146@sandoe.co.uk> <521932ed3243a79ffe22ac3c9b6c2ae1f3ffa6ef.camel@gmail.com> To: Martin Uecker X-Mailer: Apple Mail (2.3696.120.41.1.3) X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,KAM_COUK,KAM_DMARC_STATUS,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi Martin, > On 19 Jul 2023, at 11:43, Martin Uecker via Gcc-patches = wrote: >=20 > Am Mittwoch, dem 19.07.2023 um 10:29 +0100 schrieb Iain Sandoe: >>> On 19 Jul 2023, at 10:04, Martin Uecker >>> wrote: >>=20 >>>>> On 17 Jul 2023,=20 >>>>=20 >>>=20 >>>>>> 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? >>>>>=20 >>>>> There is an alternate mechanism relying on system libraries >>>>> that is >>>> possible on darwin specifically (I don=E2=80=99t 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). >>>>=20 >>>> I do not think that this solves the setjump/longjump issue - >>>> since >>>> there=E2=80=99s still a notional allocation that takes place = (it=E2=80=99s just >>>> that >>>> the mechanism for determining permissions is different). >>>>=20 >>>> 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). >>>>=20 >>>>>> 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. >>>>=20 >>>> indeed it would. >>=20 >>> I think we need a solution rather sooner than later on all archs. >>=20 >> AFAICS the heap-based trampolines can work for any arch**, this >> issue is about >> system security policy, rather than arch, specifically? >>=20 >> It seems to me that for any system security policy that permits JIT, >> (but not >> executable stack) the heap-based trampolines are viable. >=20 > I agree.=20 >=20 > BTW; One option we discussed before, was to map a page with=20 > 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. =20 > 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 =E2=80=99tide mark=E2=80=99 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)=E2=80=A6 but .. > I wonder how difficult it is to have longjmp / setjmp walk=20 > the stack in C? This would also be useful for C++ > interoperability and to free heap-allocated VLAs. =E2=80=A6 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=20 > ok to simply add a wide function pointer type that contains > address + static chain. This would require changing code,=20 > but would also work with Clang's blocks and solve other=20 > language interoperability problems, while avoiding all=20 > existing ABI issues. How does that work when passing a callback to libc (e.g. qsort?) (Implementing Clang=E2=80=99s 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=E2=80=99s supported list if someone develops = one? >=20 > 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