<div dir="ltr"><div dir="ltr">On Wed, 22 Apr 2020 at 10:49, Joe Bialek <<a href="mailto:jobialek@microsoft.com">jobialek@microsoft.com</a>> wrote:<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">




<div dir="ltr">
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
How are you going to efficiently check that something wasn't initialized at runtime? In a way that results in better codegen than just doing pattern initialization? I'm happy to see a solution but I don't see how this can be done in a way that doesn't involve
 metadata and checks. <span style="color:rgb(0,0,0);font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt">If you could do this at compile-time, you'd just issue a warning rather than let the issue hang around for someone to discover at runtime.</span></div></div></blockquote><div><br></div><div>Consider a case such as:</div><div><br></div><div>int f(int &r) { return r; }</div><div>int g() {</div><div>  int n;</div><div>  return f(n);</div><div>}</div><div><br></div><div>We certainly won't warn on this during compilation, but it's easy for us to turn this into a trap after inlining.</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"><div dir="ltr">
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
Also not clear to me what the OS is expected to do with this trap. We have a number of information leak vulnerabilities where force initialization kills the bug silently.</div></div></blockquote><div><br></div><div>Do you really mean "kills the bug"? I would certainly believe you have a number of information leak vulnerabilities where zero-init fixes the *vulnerability* (and we should definitely provide tools to harden programs against such vulnerabilities), but the program is still using an uninitialized value and still has a bug. The idea that this compiler change fixes or removes the bug is precisely the language dialect problem that I'm concerned about. Developers must still think that reading an uninitialized value is a bug (even if it's not a vulnerability any more) or they're writing a program in a language dialect where doing that is not a bug.</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"><div dir="ltr"><div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">If you have a non-recoverable trap you are now turning these bugs in to kernel crashes
 which is sort of a crappy user experience compared to just silently fixing the bug and allowing the OS to work as normal. As it is right now, we can just ignore the issues because they have no security or reliability impact which is great because it saves
 us time and money not having to service things, and customers don't have to install a code update either.</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
Joe</div>
<div id="gmail-m_-1235730156721457173appendonsend"></div>
<hr style="display:inline-block;width:98%">
<div id="gmail-m_-1235730156721457173divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> Kees Cook <<a href="mailto:keescook@chromium.org" target="_blank">keescook@chromium.org</a>><br>
<b>Sent:</b> Wednesday, April 22, 2020 10:40 AM<br>
<b>To:</b> Richard Smith <<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>><br>
<b>Cc:</b> Arthur O'Dwyer <<a href="mailto:arthur.j.odwyer@gmail.com" target="_blank">arthur.j.odwyer@gmail.com</a>>; Joe Bialek <<a href="mailto:jobialek@microsoft.com" target="_blank">jobialek@microsoft.com</a>>; Clang Dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>><br>
<b>Subject:</b> [EXTERNAL] Re: [cfe-dev] making -ftrivial-auto-var-init=zero a first-class option</font>
<div> </div>
</div>
<div><font size="2"><span style="font-size:11pt">
<div>On Tue, Apr 21, 2020 at 04:54:25PM -0700, Richard Smith wrote:<br>
> The existence of the<br>
> --long-ugly-flag-name-that-says-we'll-remove-the-feature is the way we<br>
> currently try to avoid introducing a language dialect. If we remove that<br>
> flag as is proposed, then we are effectively relitigating the question of<br>
> whether to have the feature at all.<br>
<br>
What about renaming the enable flag so it doesn't imply that zero-init<br>
is going to be removed?<br>
<br>
> And indeed it might even be OK if the initial behavior is that we *always*<br>
> zero-initialize (as Philip asked), so long as our documentation clearly<br>
> says that we do not guarantee that the value will be zero (only that we<br>
> guarantee that *if the program continues*, the value will be zero), and our<br>
> intent is that we may still produce traps or otherwise abort the<br>
> computation.<br>
<br>
Right -- I would see adding a trap path as a nice improvement. I still<br>
think it'll be be too much overhead, though, given needing to check all<br>
corners of a struct: accessing any padding bytes would need to trap,<br>
etc.<br>
<br>
-- <br>
Kees Cook<br>
</div>
</span></font></div>
</div>

</blockquote></div></div>