From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) by sourceware.org (Postfix) with ESMTPS id 9CC953858C66 for ; Wed, 19 Jul 2023 10:43:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9CC953858C66 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wm1-x330.google.com with SMTP id 5b1f17b1804b1-3fbd33a57dcso69357625e9.0 for ; Wed, 19 Jul 2023 03:43:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1689763393; x=1692355393; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=J/WFpVlAn5Lr6HrGc8OvMustL6fifSq00dwQx4cNyjk=; b=rzCygCdYdLCE5jZ7ToaeGLIVOgfZU3gXsj2hWDabXENpu1NQ0prbhlX8jrYyS+H9yX RNa6hYivGdbCSclUw5I+d+rABFI4XOBBAHpltmo4PxvEVzWS3zcoisoedl2wYzfqUTYU QiBdfANwr991V/7+VVoxKNFYKdc7+4wnEY46Q5mvOOnbL+Jqm7lloLu/wearptR8lbRO R2FpjHYeyaAk8mPODJw8tAxbUisDjvXest/Fp538UDzT+6zX1soWQd2YOTFNSxIBOTBJ lm3hnw7npijkpvTjsRS8p86VfKFwOOB3rR9ijGleJrcd7bcT/EJWHC/dC+7u/pFkwRA8 03hA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689763393; x=1692355393; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=J/WFpVlAn5Lr6HrGc8OvMustL6fifSq00dwQx4cNyjk=; b=H9whGRyWUx2983GisgEFpiPubxr0dD9xZUH3F5MHxEywbsRzH7QXvEmvnPe24vXWGC Pgpr1tRPEGGOtRdsGVFru2AdWevN8WZKEK45THMnXyI+CiXNTJViraX24rXxceR8KQeb sunRFJqbJ/J0PIrQ7vqJi4rMzUUuZ/h0tyY4cz/JCSe23A0Na4p3XytAc4gA1Mc7eoKC IbNPbl/SjLl0FY1Gcm6bheuAXyDht21g5n/1b1YLse96J8YRhCDulDajp3hoE2KUhLFp tsNr/5qgS1wJcFfgf42mwaW4eZSkOas6YclNWwERjumd3GOp1Lb06tW54pPDdHZhSX5y nlGA== X-Gm-Message-State: ABy/qLaILAZUre2Sdq2zLGLfksUbL7akQalr5cYLLGJXNeObAFjDnJyw e5zhVJ4rgnV19dnjzf/2uX8= X-Google-Smtp-Source: APBJJlFu1PX7BZDjqaSS33jpgAz9nQiqYxtI1qRtlARJ8DWzzqKMbzkNmSmIzTMrSbk4q4aEcfXmCQ== X-Received: by 2002:a7b:cbc6:0:b0:3fa:97b3:7ce0 with SMTP id n6-20020a7bcbc6000000b003fa97b37ce0mr4015720wmi.26.1689763393413; Wed, 19 Jul 2023 03:43:13 -0700 (PDT) Received: from ?IPv6:2a02:810d:acbf:c050:8e97:5915:746b:2720? ([2a02:810d:acbf:c050:8e97:5915:746b:2720]) by smtp.gmail.com with ESMTPSA id d5-20020a5d6445000000b00311299df211sm4939368wrw.77.2023.07.19.03.43.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 19 Jul 2023 03:43:12 -0700 (PDT) Message-ID: <521932ed3243a79ffe22ac3c9b6c2ae1f3ffa6ef.camel@gmail.com> Subject: Re: [PATCH] core: Support heap-based trampolines From: Martin Uecker To: Iain Sandoe Cc: GCC Patches , FX Coudert , Richard Biener , Maxim Blinov , Eric Botcazou , Jeff Law , aburgess@redhat.com Date: Wed, 19 Jul 2023 12:43:11 +0200 In-Reply-To: <81065A19-908D-438B-9C57-677674FE9146@sandoe.co.uk> References: <81065A19-908D-438B-9C57-677674FE9146@sandoe.co.uk> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.46.4-2 MIME-Version: 1.0 X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Am Mittwoch, dem 19.07.2023 um 10:29 +0100 schrieb Iain Sandoe: > Hi Martin, >=20 > > 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 targe= ts) > > > 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? > > >=20 > > > We did look at the =E2=80=9Cunused address bits=E2=80=9D mechanism th= at 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 >=20 > 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. >=20 > > > > > (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. >=20 > > I think we need a solution rather sooner than later on all archs. >=20 > AFAICS the=C2=A0 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. I agree.=C2=A0 BTW; One option we discussed before, was to map a page with=C2=A0 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=C2=A0 the stack in C? This would also be useful for C++ interoperability and to free=C2=A0 heap-allocated VLAs. 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,=C2=A0 but would also work with Clang's blocks and solve other=C2=A0 language interoperability problems, while avoiding all=C2=A0 existing=C2=A0ABI issues. >=20 > 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? I think it is a useful step forward. Martin >=20 > Iain >=20 > ** modulo the target maintainers implementing the builtins. >=20 >=20 >=20