[cfe-dev] making -ftrivial-auto-var-init=zero a first-class option

[Hubert Tong via cfe-dev]

On Tue, Apr 21, 2020 at 7:19 PM Kees Cook <keescook at chromium.org> wrote:

> On Tue, Apr 21, 2020 at 06:29:07PM -0400, Hubert Tong wrote:
> > On Tue, Apr 21, 2020 at 5:20 PM Kees Cook via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
> > >
> https://clangbuiltlinux.github.io/CBL-meetup-2020-slides/glider/Fighting_uninitialized_memory_%40_CBL_Meetup_2020.pdf
> > > tl;dr: zero-init tended to be half the cost of pattern-init, though it
> > > varied based on workload, and binary size impact fell over 95% going
> > > from pattern-init to zero-init.
> > >
> > This does not seem to indicate why zero-init is preferred over a default
> of
> > using no explicit policy in production.
>
> Do you mean "leaving things uninitialized" when you say "no explicit
> policy"?
>
Yes.

Maybe I've misunderstood. Google's goal of using auto-init is
> to eliminate uninitialized variables in production as a security
> defense.
>
This is the missing context that was not stated. The structure of your note
indicated that the first reason for using zero-init in production is for
performance and size (without indicating that some form of auto-init is
presupposed for this production environment).


> When examining zero-init vs pattern-init, there is a clear
> advantage on performance and size for zero-init.
>
Okay.


> > > as good. There are certainly exceptions here, but the bulk of the
> > > historical record on how "uninitialized" variables have been used in
> > >
> > Maybe an explanation of the scare quotes around "uninitialized" would
> help
> > clarify your position.
>
> Ah, sorry, I always use quotes (they are not intended to scare but to
> clarify) when discussing uninitialized variables in real-world contexts,
> because they are, of course, not uninitialized in the sense of them
> not having a value. The RAM contents have a value. Many people without
> compiler backgrounds think of such variables as being uncontrollable
> or meaningless, when in fact they are usually highly controllable by an
> attacker, etc.
>
Understood; thanks.


>
> > > Google (Android, Chrome OS)
> > >
> > > Both Android and Chrome OS initially started using pattern-init, but
> due
> > > to each of: the performance characteristics, the binary size changes,
> and
> > > the less robust security stance, both projects have recently committed
> > > to switching to zero-init.
> > >
> > I'm not sure that this is clear in terms of whether the statements apply
> to
> > debug/development or production. I don't think pattern-init is meant to
> be
> > a tool for production builds, which leads me to think that the above
> > statement is about debug builds, at which point I'm thinking that using
> > zero-init only serves to hide problems.
>
> The context for Google's use of zero-init was meant here to be about
> production builds.
>
Got it. Thanks.


>
> > > Upstream Linux kernel
> > >
> > > Linus Torvalds has directly stated that he wants zero-init:
> > > "So I'd like the zeroing of local variables to be a native compiler
> > > option..."
> > > "This, btw, is why I also think that the "initialize with poison" is
> > > pointless and wrong."
> > >
> > >
> https://lore.kernel.org/lkml/CAHk-=wgTM+cN7zyUZacGQDv3DuuoA4LORNPWgb1Y_Z1p4iedNQ@mail.gmail.com/
> > > Unsurprisingly, I strongly agree. ;)
> > >
> > I don't see why claiming that pattern-init is bad helps make the case for
> > zero-init.
>
> Perhaps I did not express it well enough, but both have meaningful and
> important uses. My goal here is to illustrate how zero-init is being
> used (or preferred) in many real situations, as an argument for why it
> should not be hidden behind what some might see as a scary enable flag.
>
Understood.


>
> > > Apple
> > >
> > > I can't speak meaningfully here, but I've heard rumors that they are
> > > depending on zero-init as well. Perhaps someone there can clarify how
> > > they are using these features?
> > >
> > There's a difference between "depending on zero-init" (as in, the group
> in
> > question is okay with relying on implicit zeroing on code reviews, etc.)
> > and the use of zero-init as some sort of defence-in-depth approach. Are
> > these rumours clear as to which?
>
> My understanding was the latter, but I hope to find out for real via
> this thread! :) It's not clear to me either.
>
> > > So, while I understand the earlier objections to zero-init from a
> > > "language fork" concern, I think this isn't a position that can really
> > > stand up to the reality of how many projects are using the feature
> (even
> > > via non-Clang compilers). Given that so much code is going to be built
> > > using zero-init, what's the best way for Clang to adapt here?
> >
> > It happens that there is zero-init and it's at least close enough to what
> > these projects want, but it is actually what they need?
>
> Yes, it's expressly what is desired from a security perspective. (And
> quite to the relief of that same community, comes with the least
> performance impact, which is an unfortunately uncommon scenario in
> security flaw mitigations.) I tried to detail that earlier in my email
> where it's directly what is indicated as a meaningful defense against
> the long history of real-world "uninitialized" variable attacks: setting
> everything to zero is the best defense for the entire class of flaws.
>
I'm intrigued by Richard's suggestion of trying to trap on "easy to
identify" cases of reading an uninitialized variable. I applaud the effort
being made to improve the status quo of the industry. I'm not sure I have a
better idea at this point.


>
> --
> Kees Cook
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200421/5742bf2d/attachment.html>