[Branching this into a separate conversation to avoid derailing the
patch, which isn't directly related]
On 2023-12-04 12:21, Martin Uecker wrote:
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 would argue that GNU's nested functions *are* an exception because
they're like feathers stuck on a pig to try and make it fly; I think a
significant specification effort is required to actually make it a
cleanly usable feature. It *may* be possible to implement patterns that
use C nested functions well enough *and* result in readable code, but
IMO it is easier to write clunky and unmaintainable code with it.
I empathize with Jakub's stated use case though of keeping the C
frontend support for testing purposes, but that could easily be done
behind a flag, or by putting nested C func deprecation behind a flag.
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.
I suppose you mean source code changes even in correct code just to
comply with the flag? I don't disagree for cases like -Warray-bounds,
but for warnings/errors that are more deterministic in nature (like
-Werror=trampolines), they're going to point at actual problems and
larger projects and distributions will usually prefer to at least track
them, if not actually fix them. For Fedora we tend to provide macro
overrides for packages that need to explicitly disable a security
related flag.
Thanks,
Sid
