On Thu, 6 Aug 2020, Kees Cook wrote: > On Thu, Aug 06, 2020 at 10:37:43AM +0200, Richard Biener wrote: > > 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. > > I've viewed stack erasure as separate from register clearing. The > "when" of stack erasure tends to define which things are being defended > against. If the stack is being erased on function entry, you're defending > against all the various "uninitialized" variable attacks (which can be > info exposures, flow control redirection, etc). If it's on function exit, > this is more aimed at avoiding stale data and minimizing what's available > during an attack (and it also provides similar "uninit" defenses, just > in a different way). And FWIW, past benchmarks on this appear to indicate > erase-on-entry is more cache-friendly.
So I originally thought this was about leaking security sensitive data to callers and thus we want to define API entries to not leak any data from callees other than via the ABI defined return values or global memory the callee chooses to populate. Clearing registers not involved in returning data is one part but then contents of such registers could also reside in spill slots which means you have to clear those as well. And yes, even local automatic variables of the callee fall into the category and thus 'stack-erasure' would be required. To appropriately have such a "security boundary" at function return you _do_ have to do the clearing at function return though. But it's a completely different topic and it seems the patch was not intended to help the folks that also ask for "secure"_memset the compiler isn't supposed to optimize away as dead. Richard.
