https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116457
--- Comment #6 from Arsen Arsenović <arsen at gcc dot gnu.org> --- (In reply to Andrew Pinski from comment #5) > > but it is already in reliable real-world use. > > Then that real world use is broken. > > >It's a pretty isolated change and doesn't impact any later stages of > >compilation. > > It is not exactly isolated, that is if there is an option, someone will try > it and then get broken code. Did you run the full GCC testsuite with it > turned on to see what breaks? Do you have a formal definition of what works > with it and what does NOT? That isn't really a useful measure - I suspect a lot of the testsuite would break with -Ofast forced-on, for instance. WRT possible user error, one needs to opt-in for this (via an attribute, but the plugin this'd replace currently also automatically shuffles vtable-style structs and I think that is a footgun but it is what it is) > Why have a seperate option for the seed? Rather than reuse > -frandomize-layout-seed ? Is it because you want to force folks to always > use a different seed from the seed which is going to be there for > reproducibility or just because it is another obscure option? I see at least one reason: not having to interact with Kconfig more than absolutely necessary. > This could introduce new security issues just by having it, rather than > security by obscurity. For an example someone's code is not ready for this > layout change but then it messes up. > > Also why only C and not C++? At least in C++ you have local linkage structs > (e.g. structs defined inside an anonymous namespaces) so you don't have a > push to force things to be consistent between TUs. this wouldn't be the first kernel-induced C-only feature, really > Does clang (or the plugin) warn if a struct with randomize_layout is used > with an exported symbol? what about taking the address and then passing it > around? Do es it have some kind of flow sensitive warning because without > that it is 100% a security issue waiting to happen. no, the plugin is extremely primitive. due to the seed being constant across a kernel build, there isn't really a problem wrt linking TUs together. FWIW, I mentioned at Cauldron that I have a fix that makes the plugin not break debug info generation, that'd also work for this case I think. I'm yet to polish it because testing the Linux side of it seems non-trivial, and because I'll need to edit all frontends to add the new hook, so testing the GCC side is also not too trivial. I need to finish up a lot of non-GCC-related work currently, though :/ doing this in the C frontend only solves some of those issues, though ;)
