On Wed, 5 Aug 2020, Qing Zhao wrote: > >> > >> From The SECURE project and GCC in GCC Cauldron 2018: > >> > >> Speaker: Graham Markall > >> > >> The SECURE project is a 15 month program funded by Innovate UK, to > >> take well known security techniques from academia and make them > >> generally available in standard compilers, specfically GCC and LLVM. > >> An explicit objective is for those techniques to be incorporated in > >> the upstream versions of compilers. The Cauldron takes place in the > >> final month of the project and this talk will present the technical > >> details of some of the techniques implemented, and review those that > >> are yet to be implemented. A particular focus of this talk will be on > >> verifying that the implemetnation is correct, which can be a bigger > >> challenge than the implementation. > >> > >> Techniques to be covered in the project include the following: > >> > >> Stack and register erasure. Ensuring that on return from a function, > >> no data is left lying on the stack or in registers. Particular > >> challenges are in dealing with inlining, shrink wrapping and caching. > >> > >> This patch implemens register erasure. > > > > Part of it, yes. While I can see abnormal transfer of control is difficult > > exception handling is used too wide spread to be ignored. What's the plan > > there? > > > > So can we also see the other parts? In particular I wonder whether exposing > > just register clearing (in this fine-grained manner) is required and useful > > rather than thinking of a better interface for the whole thing? > > You mean to provide an integrated interface for both stack and register > erasure for security purpose? > > However, Is stack erasure at function return really a better idea than > zero-init auto-variables in the beginning of the function? > > We had some discussion with Kees Cook several weeks ago on the idea of > stack erasure at function return, Kees provided the following comments: > > "But back to why I don't think it's the right approach: > > Based on the performance measurements of pattern-init and zero-init > in Clang, MSVC, and the kernel plugin, it's clear that adding these > initializations has measurable performance cost. Doing it at function > exit means performing large unconditional wipes. Doing it at function > entry means initializations can be dead-store eliminated and highly > optimized. Given the current debates on the measurable performance > difference between pattern and zero initialization (even in the face of > existing dead-store elimination), I would expect wipe-on-function-exit to > be outside the acceptable tolerance for performance impact. (Additionally, > we've seen negative cache effects on wiping memory when the CPU is done > using it, though this is more pronounced in heap wiping. Zeroing at > free is about twice as expensive as zeroing at free time due to cache > temporality. This is true for the stack as well, but it's not as high.)” > > From my understanding, the major issue with stack erasure at function > result is the big performance overhead, And these performance overhead > cannot be reduced with compiler optimizations since those additional > wiping insns are inserted at the end of the routine. > > Based on the previous discussion with Kees, I don’t think that stack > erasure at function return is a good idea, Instead, we might provide an > alternative approach: zero/pattern init to auto-variables. (This > functionality has Been available in LLVM already) This will be another > patch we want to add to GCC for the security purpose in general. > > So, I think for the current patch, -fzero-call-used-regs should be good > enough. > > Any comments?
OK, so -fzero-call-used-regs is a ROP mitigation technique. To me it sounded more like a mitigation against information leaks which then would be highly incomplete w/o spill slot clearing. Like we had that discussion on secure erase of memory that should not be DSEd. This needs to be reflected in the documentation and eventually the option naming? Like -frop-protection=... similar in spirit to how we have -fcf-protection=... (though that as well is supposed to provide ROP mitigation). I'm not very familiar with ROP [mitigation] techinques, so I'm no longer questioning usefulness of this patch but leave that to others (and thus final approval). I'm continuing to question the plethora of target hooks you add and will ask for better user-level documentation. Richard.
