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 C46663858002 for ; Wed, 19 Jul 2023 09:29:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C46663858002 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 84779 invoked from network); 19 Jul 2023 09:29:48 -0000 X-APM-Out-ID: 16897589888477 X-APM-Authkey: 257869/1(257869/1) 9 Received: from unknown (HELO smtpclient.apple) (81.138.1.83) by smtp001.apm-internet.net with SMTP; 19 Jul 2023 09:29:48 -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: Date: Wed, 19 Jul 2023 10:29:47 +0100 Cc: GCC Patches , FX Coudert , Richard Biener , Maxim Blinov , Eric Botcazou , Jeff Law , aburgess@redhat.com Content-Transfer-Encoding: quoted-printable Message-Id: <81065A19-908D-438B-9C57-677674FE9146@sandoe.co.uk> References: 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,KAM_SHORT,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 10:04, Martin Uecker wrote: >>> 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=99= s 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? >>=20 >> We did look at the =E2=80=9Cunused address bits=E2=80=9D 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). >>=20 >> Andrew Burgess did the original work he might have comments on >> alternatives we tried >>=20 >=20 > For reference, I proposed a patch for this in 2018. It was not > accepted because minimum alignment for functions would increase > for some archs: >=20 > 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=20 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?!) >>>=20 >>> 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. > 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=E2=80=99s supported list if someone develops one? Iain ** modulo the target maintainers implementing the builtins.