https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116457
--- Comment #12 from Andrew Pinski <pinskia at gcc dot gnu.org> --- (In reply to Kees Cook from comment #4) > This feature is designed as a "security through obscurity" feature that has > real-world benefits to specialized high-security deployments where > performance is not a concern. > > It is never expected to be compatible with the C standard; it operates as a > language extension. And it is C only -- there's no desire to have this work > with C++. > > As for "security issue waiting to happen", I'd be curious to hear what > you're considering. Both designated initialization and casting is already > explicitly considered in the Clang and GCC plugin implementations. Not really. I looked into the implementation of the warning: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/scripts/gcc-plugins/randomize_layout_plugin.c#n717 And it is just as bad as the way GCC outputs strict aliasing warnings in the front-end, very easy worked around by using `void*` or even a pointer addition (since there is no case for POINTER_PLUS). Or even just doing: struct a *b = &c; int *d = (int*)b; Since you get 2 statements right after ssa (before ccp). And no warning when dealing with casting to an integer type. > > So, no doubt, it's a really wild feature, but it is already in reliable > real-world use. Not bringing it upstream into GCC doesn't make much sense to > me. It's a pretty isolated change and doesn't impact any later stages of > compilation. Without the full IPA based analysis of making sure people don't use it incorrectly, this should NOT go in. And right now there is there is none and I don't think anyone is willing to implement it since it will take some time. So many other random features make better sense to add for security than implementing this. Like doing better static anlaysis and better auditing of code.
