Am Montag, dem 04.12.2023 um 11:46 -0500 schrieb Siddhesh Poyarekar: > On 2023-12-04 11:39, Andreas Schwab wrote: > > On Dez 04 2023, Siddhesh Poyarekar wrote: > > > > > For hardened code in C, I think we really should look to step away from > > > nested functions instead of adding ways to continue supporting it. There's > > > probably a larger conversation to be had about the utility of nested > > > functions in general for C (and whether this GCC extension should be > > > deprecated altogether in future), but I feel like the -fhardened subset > > > gives us the opportunity to enforce at least a safe subset for now, > > > possibly extending it in future. > > > > Nested functions by itself don't need a trampoline, only if the address > > of it is passed outside the containing function's scope (as a callback, > > for example). > > Yes, that's why I said that the conversation about deprecating the C > nested functions extension is a broader one (and hence for gcc 15) that > will likely involve the question of whether dropping the extension > altogether gives any benefit or if dropping support for on-stack > trampolines is sufficient. On-heap trampolines are maybe slightly > better in that they don't need an executable stack, but defaulting to > on-heap trampolines for -fhardened seems like a lost opportunity to > enforce better user code.
I do not really agree with that. Nested functions can substantially improve code quality and in C can avoid type unsafe use of void* pointers in callbacks. The code is often much better with nested functions than without. Nested functions and lambdas (i.e. anonymous nested functions) are used in many languages because they make code better and GNU's nested function are no exception. So I disagree with the idea that discouraging nested functions leads to better code - I think the exact opposite is true. I am generally wary of mitigations that may make exploitation of buffer overflows a bit harder while increasing the likelihood of buffer overflows by reducing type safety and/or code quality. But I would agree that trampolines are generally problematic. A better strategy would be wide function pointer type (as in Apple' Blocks extension). Alternatively, an explicit way to obtain the static chain for a nested function which could be used with __builtin_call_with_static_chain could also work. But in any case, I think it diminishes the value of -fhardening it if requires source code changes, because then it is not as easy to simply turn it on in larger projects / distributitions. Martin > > Thanks, > Sid
