[cfe-dev] [llvm-dev] [RFC] Zeroing Caller Saved Regs

[David Chisnall via cfe-dev]

Hi Bill,

The thing missing from the RFC, though tangentially referenced in a couple of the links, is the threat model for this.

We’ve looked in the past (and had a paper at EuroS&P a few years ago) at the ways in which the compiler can leak secrets that the C abstract machine believes are erased but can be found via a stack memory safety gadget.  Fully addressing this requires zeroing spill slots and may also require spilling temporary registers across calls rather than placing values in callee-save registers (though if *all* code is compiled defensively, then the callee can be trusted to zero spill slots for these).

It appears as if this proposal is to address a weaker security model: leaking secrets via transient execution vulnerabilities.  As such, it is not concerned with secrets spilled to the stack or leaked from the caller to callee in callee-save registers.  

The latter almost makes sense.  These registers are normally spilled unconditionally on entry to a function if they are used.  The presence of shrink wrapping invalidates this assumption though, and there are transient execution paths through a function that uses shrink wrapping that will leak secrets from the caller.  I would therefore expect that this option would disable shrink wrapping.

The former makes less sense to me.  Anything that loads from the stack and does something with the result is a potential gadget for leaking secrets spilled to the stack by a prior call via transient execution side channels and, even in the presence of this defence, it seems likely that there are a large number of useful gadgets remaining.  

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.  

David

> On 7 Aug 2020, at 00:12, Bill Wendling via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> [This feature addresses https://bugs.llvm.org/show_bug.cgi?id=37880
> and https://github.com/KSPP/linux/issues/84.]
> 
> Clang has been ramping up its support of the Linux kernel. We recently
> added "asm goto with outputs", a long requested feature. We want to
> continue building our relationship with the Linux community.
> 
> KSPP is a project to improve security in the Linux kernel, through
> both kernel changes and compiler features. One compiler feature they
> want is the ability to zero out caller-saved registers on function
> return as a defense against stale register contents being used as a
> side-channel or speculation path.
> 
> The option will be "opt-in" for each target. Targets that don't
> support the flag should probably emit a warning or error.
> 
> Our proposal for the feature is modeled off of H. J. Lu's
> description[1] (copied with some modifications):
> 
> ```
> Add -mzero-caller-saved-regs=[skip|used-gpr|all-gpr|used|all]
> command-line option and zero_caller_saved_regs function attributes:
> 
> * Don't zero caller-saved registers upon function return (default):
> 
>    -mzero-caller-saved-regs=skip
>    zero_caller_saved_regs("skip")
> 
> * Zero used caller-saved integer registers upon function return:
> 
>    -mzero-caller-saved-regs=used-gpr
>    zero_caller_saved_regs("used-gpr")
> 
> * Zero all integer registers upon function return:
> 
>    -mzero-caller-saved-regs=all-gpr
>    zero_caller_saved_regs("all-gpr")
> 
> * Zero used caller-saved integer and vector registers upon function return:
> 
>    -mzero-caller-saved-regs=used
>    zero_caller_saved_regs("used")
> 
> * Zero all caller-saved integer and vector registers upon function return:
> 
>    -mzero-caller-saved-regs=all
>    zero_caller_saved_regs("all")
> ```
> 
> -bw
> 
> [1] https://github.com/clearlinux-pkgs/gcc/blob/master/0001-x86-Add-mzero-caller.patch
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>