<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Apr 21, 2020 at 7:19 PM Kees Cook <<a href="mailto:keescook@chromium.org" target="_blank">keescook@chromium.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, Apr 21, 2020 at 06:29:07PM -0400, Hubert Tong wrote:<br>
> On Tue, Apr 21, 2020 at 5:20 PM Kees Cook via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br>
> > <a href="https://clangbuiltlinux.github.io/CBL-meetup-2020-slides/glider/Fighting_uninitialized_memory_%40_CBL_Meetup_2020.pdf" rel="noreferrer" target="_blank">https://clangbuiltlinux.github.io/CBL-meetup-2020-slides/glider/Fighting_uninitialized_memory_%40_CBL_Meetup_2020.pdf</a><br>
> > tl;dr: zero-init tended to be half the cost of pattern-init, though it<br>
> > varied based on workload, and binary size impact fell over 95% going<br>
> > from pattern-init to zero-init.<br>
> ><br>
> This does not seem to indicate why zero-init is preferred over a default of<br>
> using no explicit policy in production.<br>
<br>
Do you mean "leaving things uninitialized" when you say "no explicit<br>
policy"?<br></blockquote><div>Yes. <br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Maybe I've misunderstood. Google's goal of using auto-init is<br>
to eliminate uninitialized variables in production as a security<br>
defense.<br></blockquote><div>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).<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">When examining zero-init vs pattern-init, there is a clear<br>
advantage on performance and size for zero-init.<br></blockquote>Okay.</div><div class="gmail_quote"> <br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> > as good. There are certainly exceptions here, but the bulk of the<br>
> > historical record on how "uninitialized" variables have been used in<br>
> ><br>
> Maybe an explanation of the scare quotes around "uninitialized" would help<br>
> clarify your position.<br>
<br>
Ah, sorry, I always use quotes (they are not intended to scare but to<br>
clarify) when discussing uninitialized variables in real-world contexts,<br>
because they are, of course, not uninitialized in the sense of them<br>
not having a value. The RAM contents have a value. Many people without<br>
compiler backgrounds think of such variables as being uncontrollable<br>
or meaningless, when in fact they are usually highly controllable by an<br>
attacker, etc.<br></blockquote><div>Understood; thanks.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> > Google (Android, Chrome OS)<br>
> ><br>
> > Both Android and Chrome OS initially started using pattern-init, but due<br>
> > to each of: the performance characteristics, the binary size changes, and<br>
> > the less robust security stance, both projects have recently committed<br>
> > to switching to zero-init.<br>
> ><br>
> I'm not sure that this is clear in terms of whether the statements apply to<br>
> debug/development or production. I don't think pattern-init is meant to be<br>
> a tool for production builds, which leads me to think that the above<br>
> statement is about debug builds, at which point I'm thinking that using<br>
> zero-init only serves to hide problems.<br>
<br>
The context for Google's use of zero-init was meant here to be about<br>
production builds.<br></blockquote><div>Got it. Thanks.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> > Upstream Linux kernel<br>
> ><br>
> > Linus Torvalds has directly stated that he wants zero-init:<br>
> > "So I'd like the zeroing of local variables to be a native compiler<br>
> > option..."<br>
> > "This, btw, is why I also think that the "initialize with poison" is<br>
> > pointless and wrong."<br>
> ><br>
> > <a href="https://lore.kernel.org/lkml/CAHk-=wgTM+cN7zyUZacGQDv3DuuoA4LORNPWgb1Y_Z1p4iedNQ@mail.gmail.com/" rel="noreferrer" target="_blank">https://lore.kernel.org/lkml/CAHk-=wgTM+cN7zyUZacGQDv3DuuoA4LORNPWgb1Y_Z1p4iedNQ@mail.gmail.com/</a><br>
> > Unsurprisingly, I strongly agree. ;)<br>
> ><br>
> I don't see why claiming that pattern-init is bad helps make the case for<br>
> zero-init.<br>
<br>
Perhaps I did not express it well enough, but both have meaningful and<br>
important uses. My goal here is to illustrate how zero-init is being<br>
used (or preferred) in many real situations, as an argument for why it<br>
should not be hidden behind what some might see as a scary enable flag.<br></blockquote><div>Understood.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> > Apple<br>
> ><br>
> > I can't speak meaningfully here, but I've heard rumors that they are<br>
> > depending on zero-init as well. Perhaps someone there can clarify how<br>
> > they are using these features?<br>
> ><br>
> There's a difference between "depending on zero-init" (as in, the group in<br>
> question is okay with relying on implicit zeroing on code reviews, etc.)<br>
> and the use of zero-init as some sort of defence-in-depth approach. Are<br>
> these rumours clear as to which?<br>
<br>
My understanding was the latter, but I hope to find out for real via<br>
this thread! :) It's not clear to me either.<br>
<br>
> > So, while I understand the earlier objections to zero-init from a<br>
> > "language fork" concern, I think this isn't a position that can really<br>
> > stand up to the reality of how many projects are using the feature (even<br>
> > via non-Clang compilers). Given that so much code is going to be built<br>
> > using zero-init, what's the best way for Clang to adapt here?<br>
> <br>
> It happens that there is zero-init and it's at least close enough to what<br>
> these projects want, but it is actually what they need?<br>
<br>
Yes, it's expressly what is desired from a security perspective. (And<br>
quite to the relief of that same community, comes with the least<br>
performance impact, which is an unfortunately uncommon scenario in<br>
security flaw mitigations.) I tried to detail that earlier in my email<br>
where it's directly what is indicated as a meaningful defense against<br>
the long history of real-world "uninitialized" variable attacks: setting<br>
everything to zero is the best defense for the entire class of flaws.<br></blockquote><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
-- <br>
Kees Cook<br>
</blockquote></div></div>