> On Aug 7, 2020, at 1:21 AM, Richard Biener <rguent...@suse.de> wrote:
>
> 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.
In the following slides of The Secure Project and GCC:
https://gmarkall.files.wordpress.com/2018/09/secure_and_gcc.pdf
<https://gmarkall.files.wordpress.com/2018/09/secure_and_gcc.pdf>
It was mentioned that the the stack erase patch For GCC would be submitted to
gcc upstream soon (in 2018).
I am wondering whether that patch has been submitted and discussed already?
Qing
>
> 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.
