From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) by sourceware.org (Postfix) with ESMTPS id 060153858C33 for ; Wed, 19 Jul 2023 15:18:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 060153858C33 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-x333.google.com with SMTP id 5b1f17b1804b1-3fbc5d5742bso70443405e9.2 for ; Wed, 19 Jul 2023 08:18:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1689779929; x=1692371929; 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=Z9QOxiPlrFjKcsr+ratM7E8qecLyNBAduHsHZ40NBIQ=; b=MEmZI2xrkphxiDiOT1EBbFYaPf1D0TxYzh8RYCHq1e7cz2AX9QYnXsH4972NmqsJfc S8ibIjEV3kKIIVJ0zmndrTZvFscySfhAVsv1qe8a5hFYYvpRlYACApgm+uqgkaGcMubA snVgd44hFORLOrcaooH1y+6Lx2+fKVq5obNY+fSLGOOXyTEOiaK37wpFwEjbjQdwzwGm KRb0tXBMcsRRJvkhGYfT97IESil43qID6BAjZtk79gxAeefomg8p4AHaEI9ZTdCMepYx doMAUyDtSCec5MnF4Ehp0qSF//pMA+ViiQ1pipUMId/EqQw28+Is9gmBNs1ZJbksU/i1 SdrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689779929; x=1692371929; 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=Z9QOxiPlrFjKcsr+ratM7E8qecLyNBAduHsHZ40NBIQ=; b=Z9V1bhV1NNB+K4HvI6e63W3MoSDXdvuBa43TOWSCzFmyCDn2JmKWnMagPur7owjlWA 9DUcg4fA2x1qvHRy0uvTI+WSFjnjAjkoejJ0T5WTjjeKe84RPivtkceVS66Cwbb5JHNT 4D74NTcWk8854j3OOjCMmb3IC7k6/VcmuZEPyan208IwB6AUiqcAzqnBwxbUYebFgIY0 6VxkMd2yPwU2Yh3esKbVxEac6EyXnTFb0WZQr8o9iyGqpql4jAU5q4FEGP8RZYaCIIup qeyayER/dOLt+yUYibD2o0pmKylsY3Lhs4Mt6CZCQitmCQhPzcdgI35rbeSN6GjG+9FW 0+gQ== X-Gm-Message-State: ABy/qLZimfVu3Jx/5IHd8zV+g2TDI8Mo9irrX6DxqeROCGLGpRcojWlp feOfUI51ockFT4tlmpi43c0= X-Google-Smtp-Source: APBJJlFTIROBLq1wW6SFrOWThLvt4OafHwlegpDAkAQxNBD49FnlONwo9myK43cuj3mA5XM60Z7JEg== X-Received: by 2002:a5d:58ca:0:b0:315:9fb7:bd9 with SMTP id o10-20020a5d58ca000000b003159fb70bd9mr105546wrf.69.1689779929067; Wed, 19 Jul 2023 08:18:49 -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 z13-20020adfe54d000000b003144b50034esm5549521wrm.110.2023.07.19.08.18.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 19 Jul 2023 08:18:48 -0700 (PDT) Message-ID: <16d8956934aed12785c41754c800c798b4c7e351.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 17:18:47 +0200 In-Reply-To: References: <81065A19-908D-438B-9C57-677674FE9146@sandoe.co.uk> <521932ed3243a79ffe22ac3c9b6c2ae1f3ffa6ef.camel@gmail.com> 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,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 15:23 +0100 schrieb Iain Sandoe: > Hi Martin, >=20 > > 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: >=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 t= argets) > > > > > 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 > > > > > > 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. > >=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. >=20 > That reads similar to the scheme Apple have implemented for libobjc and l= ibffi. > 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 s= hared > 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.=C2=A0=20 >=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... >=20 > 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 sav= ed data in the > trampoline (not used as part of the execution, but only as part of the al= location > mangement)=E2=80=A6 but .. >=20 > > I wonder how difficult it is to have longjmp / setjmp walk=20 > > the stack in C?=C2=A0=C2=A0 This would also be useful for C++ > > interoperability and to free=C2=A0 heap-allocated VLAs. >=20 > =E2=80=A6 this would be a better solution (as we can see trampolines are = a small > leak c.f. the general uses)? >=20 > > 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.=C2=A0 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. >=20 > How does that work when passing a callback to libc (e.g. qsort?) This would not work because it would be an ABI change, but because it solves a general problem and would plug a major language interoperability issue between C and all languages that have callable objects or nested functions, I think one could make a good case that such an extension goes into C standard together with a set of enhanced=C2=A0interfaces. I have an initial proposal here: http://www2.open-std.org/JTC1/SC22/WG14/www/docs/n2787.pdf One could combine this with other solutions where a user created trampoline with explicit allocation and deallocation calls such a wide pointer, i.e. one has a library function that takes a wide pointer and returns regular function pointer that points to an allocated trampoline the user has to free explicitely. BTW: having a GCC builtin that returns the static chain for a nested function so that it can later be used with __builtin_call_with_static_chain would also be helpful. > (Implementing Clang=E2=80=99s blocks is also on my TODO, but a different = discussion ;)) It would be nice to make this compatible. Martin > > > 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 on= e? > >=20 > > I think it is a useful step forward. >=20 > Assembled maintainers, do you think this is OK for trunk given the variou= s > discussions above? >=20 > thanks > Iain >=20