[llvm-dev] [RFC] Zeroing Caller Saved Regs
David Chisnall via llvm-dev
llvm-dev at lists.llvm.org
Mon Aug 10 03:34:10 PDT 2020
On 07/08/2020 23:28, Kees Cook wrote:
> On Fri, Aug 7, 2020 at 1:18 AM David Chisnall
> <David.Chisnall at cl.cam.ac.uk> wrote:
>> I think it would be useful for the discussion to have a clear threat model that this intends to defend against and a rough analysis of the security benefits that this is believed to bring.
> I view this as being even more about a ROP defense. Dealing with spill
> slots is, IMO, a separate issue, more related to the auto-var-init
> work (though that would be stack erasure on function exit, rather than
> entry, which addresses a different set of issues). I think this thread
> from the GCC list has some good details on the ROP defense:
This link gives two motivations:
1. Reducing information leak (which I find unconvincing, because there's
a lot more left on the stack than in caller-save registers).
2. Reducing ROP gadgets.
Unfortunately, for claim 2 they cite a paper that is behind a paywall,
so I can't easily see what that's doing and I'll have to guess what the
Caller-save registers are intuitively useful in the first gadget in a
ROP sequence, because the current frame will have put values into them
(and so they are most likely to hold attacker-controlled values). I can
imagine quite easily a paper that shows that you break the first gadget
in a chain with this mitigation.
It's possible that it would also significantly reduce the number of
total gadgets if each ret is preceeded by the zeroing sequence,
effectively denying the ability for the attacker to use these registers.
Unfortunately, to be able to make arbitrary calls they would just need
one unguarded forward control-flow edge that loaded a function pointer
and its arguments from the stack, and I can't imagine that such a gadget
is absent from most nontrivial codebases. I'd like to see an analysis
of the gadgets remaining when this mitigation is used.
I don't object to adding a flag that makes the Linux kernel slower but
if it is being advertised as a security feature then I would like to see
some evidence that it does something other than require automated attack
tools pick a different set of gadgets to use.
More information about the llvm-dev