Hi Martin, > On 19 Jul 2023, at 10:04, Martin Uecker <ma.uec...@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? >> >> We did look at the “unused address bits” 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). >> >> Andrew Burgess did the original work he might have comments on >> alternatives we tried >> > > For reference, I proposed a patch for this in 2018. It was not > accepted because minimum alignment for functions would increase > for some archs: > > 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 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?!) >>> >>> 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. 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? Iain ** modulo the target maintainers implementing the builtins.
