On Aug 7, 2020, Qing Zhao <qing.z...@oracle.com> wrote: > So, I believe that the call-used registers (especially those registers > that pass parameters) need to be zeroed > In order to mitigate the ROP attack.
Erhm, I don't get why it's important that they be zeroed. It seems to me that restoring their original values, or setting them to random values, would be just as good defenses from having them set within the function to perform a ROP attack than zeroing them. The point is to get rid of whatever value the attacker chose within the function. One could even argue that restoring the caller value is better than setting to zero, because the result is not predictable from within the function. OTOH, there's the flip side, that the function *could* be changed so as to modify the stack slot in which the register is saved, if there's hostile code running. (it wouldn't be modified by "normal" code) Code that sets the register to zero in the epilogue would be much harder for an attacker to change indeed. > I think that moving how to zeroing the registers part to each target > will be a better solution since each target has > Better idea on how to use the most efficient insns to do the work. It's certainly good to allow machine-specific optimized code sequences, but it would certainly be desirable to have a machine-independent fallback. It doesn't seem exceedingly hard to loop over the registers and emit a (set (reg:M N) (const_int 0)) for each one that is to be zeroed out. -- Alexandre Oliva, happy hacker https://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer
