[Bug c/77992] Failures to initialize padding bytes -- causing many information leaks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77992 --- Comment #13 from Kangjie Lu --- (In reply to jos...@codesourcery.com from comment #10) > If you care about information in bytes that are not part of a field with > other semantic significance, you should use -Werror=padded to get errors > on structs with padding and use that information to add explicit dummy > fields in the source code where there was padding. Once there are > explicit dummy fields, their values will be preserved by the compiler, so > you can either zero the whole struct with memset and rely on the zeroing > of dummy fields not being optimized away, or use a struct initializer and > rely on it implicitly zeroing those fields. (Of course this may reduce > efficiency as optimizations such as SRA now need to track values of those > fields, whereas they do not need to track values of padding.) This is a candidate solution, but I think it cannot scale. Given that the Linux kernel has tens of thousands of modules, the idea of manually initializing padding bytes for all data structures will be definitely declined by the Linux community. My opinion is still that, as padding is introduced by compilers and is "invisible" to developers, initializing padding should be done by on the compiler side.
[Bug c/77992] Failures to initialize padding bytes -- causing many information leaks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77992 --- Comment #12 from Kangjie Lu --- (In reply to Andreas Schwab from comment #11) > The problem with that strategy is that padding is architecture dependent, > and care must be taken not to introduce ABI breakage. Agreed. Or a developer will have to write corresponding dummy fields for various platforms, which will be annoying for code maintenance.
[Bug c/77992] Failures to initialize padding bytes -- causing many information leaks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77992 --- Comment #11 from Andreas Schwab --- The problem with that strategy is that padding is architecture dependent, and care must be taken not to introduce ABI breakage.
[Bug c/77992] Failures to initialize padding bytes -- causing many information leaks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77992 --- Comment #10 from joseph at codesourcery dot com --- If you care about information in bytes that are not part of a field with other semantic significance, you should use -Werror=padded to get errors on structs with padding and use that information to add explicit dummy fields in the source code where there was padding. Once there are explicit dummy fields, their values will be preserved by the compiler, so you can either zero the whole struct with memset and rely on the zeroing of dummy fields not being optimized away, or use a struct initializer and rely on it implicitly zeroing those fields. (Of course this may reduce efficiency as optimizations such as SRA now need to track values of those fields, whereas they do not need to track values of padding.)
[Bug c/77992] Failures to initialize padding bytes -- causing many information leaks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77992 --- Comment #9 from Kangjie Lu --- (In reply to Andrew Pinski from comment #8) > A simple google search (secure memset [glibc]) finds a few things: > http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1381.pdf > > https://sourceware.org/ml/libc-alpha/2014-12/msg00506.html > > https://www.securecoding.cert.org/confluence/display/c/MSC06-C. > +Beware+of+compiler+optimizations > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=8537 Thanks for sharing these interesting links. Sure, compiler optimizations sometime may aggressively eliminate dead code. As I mentioned in my last reply, this is not a problem in our work because our instrumentation is inserted after all LLVM optimization passes. The inserted memset will not be removed. Back to my original problem, many Linux kernel developers also hope GCC can provide a feature (like a compilation option) that can zero-initialize padding bytes. Fixing these information leaks manually will make the code maintenance extremely difficult. Anyway, I just wanted to report this issue :)
[Bug c/77992] Failures to initialize padding bytes -- causing many information leaks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77992 --- Comment #8 from Andrew Pinski --- A simple google search (secure memset [glibc]) finds a few things: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1381.pdf https://sourceware.org/ml/libc-alpha/2014-12/msg00506.html https://www.securecoding.cert.org/confluence/display/c/MSC06-C.+Beware+of+compiler+optimizations https://gcc.gnu.org/bugzilla/show_bug.cgi?id=8537
[Bug c/77992] Failures to initialize padding bytes -- causing many information leaks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77992 --- Comment #7 from Kangjie Lu --- (In reply to Andrew Pinski from comment #6) > >More information can be found in our research paper: > >http://www.cc.gatech.edu/~klu38/publications/unisan-ccs16.pdf > > > You research paper is wrong and does not consider C is an inherently > insecure language to be begin with. There are many other things wrong with > it. Like for an example recommending the use of memset when you want to > hide the stores from the compiler. There is already a thread on the glibc > mailing list about this exact thing about adding a secure memset which is > GCC is not going to optimize away. Thanks for your feedback. We do think C is not safe language and that's why we want to secure programs written in C. Could you provide me more information about the thread. We use LLVM instead of GCC. Our instrumentation is inserted after optimization passes. Thanks!
[Bug c/77992] Failures to initialize padding bytes -- causing many information leaks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77992 --- Comment #6 from Andrew Pinski --- >More information can be found in our research paper: >http://www.cc.gatech.edu/~klu38/publications/unisan-ccs16.pdf You research paper is wrong and does not consider C is an inherently insecure language to be begin with. There are many other things wrong with it. Like for an example recommending the use of memset when you want to hide the stores from the compiler. There is already a thread on the glibc mailing list about this exact thing about adding a secure memset which is GCC is not going to optimize away.
[Bug c/77992] Failures to initialize padding bytes -- causing many information leaks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77992 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|driver |c Resolution|--- |INVALID Severity|critical|normal --- Comment #5 from Andrew Pinski --- Again C is not the language you want for this. Also if you want this you should use a loop which hides the stores from GCC Using inline-asm. >Besides performance (I understand that the unaligned initialization could be >expensive), any other reasons? Because there is no reason to do it that way. You said to initialize only those fields anyways.
