4 ms·

That strategy won't fly with IBT. Now all software must pay the price and miss out on important mitigations, for all eternity, just because of some largely unu

• mananaysiempre 3y ago
  IBT is already further along here. The hypothetical solution for executable stacks is to recompile all of your nested-function-using or -calling code with -ftrampolines (except that won’t work without the patch above—silently, really GCC?..). The already real and working solution for IBT is to recompile all of your indirect-branch-using code with -fcf-protection=branch. So, ignoring the fact that nested functions are in practice much rarer, if you accept the former as valid you’ll need to accept the latter as well, as far as logic as concerned. I wouldn’t characterize this as a “largely unused feature in one compiler” screwing things up, but rather as the ABI on most Linux and -adjacent platforms (except SysV Itanium and FDPIC IIRC) being incapable of supporting closures (without executable stacks). That these are missing from standard C, and only present in languages that are either niche (Pascal, Ada) or don’t care about following the platform ABI (Rust, Go, C++’s lambdas), is a defect of C (and that’s at least a somewhat popular opinion among ISO C committee members[1]). Of course, OpenBSD essentially does not have a stable ABI, so it’s much freer to experiment here. [1] https://thephd.dev/lambdas-nested-functions-block-expressions-oh-my https://thephd.dev/lambdas-nested-functions-block-expression...