<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">We still make fixes to up level code. We just don’t have to fix existing in-market code.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">For the end-users who consume the binaries you are generating, the behavior I am describing is preferable to having to install an update to fix a fault that could have been silently fixed. People don’t like installing updates and often
don’t. It also saves a lot of money on our end to not be required to service something that is working. We can verify the code is working correctly, make the change only in our active development branch for the next version of the product, and move on.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Joe<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> David Blaikie <dblaikie@gmail.com> <br>
<b>Sent:</b> Wednesday, April 22, 2020 11:07 AM<br>
<b>To:</b> Joe Bialek <jobialek@microsoft.com><br>
<b>Cc:</b> Kees Cook <keescook@chromium.org>; Richard Smith <richard@metafoo.co.uk>; Clang Dev <cfe-dev@lists.llvm.org><br>
<b>Subject:</b> Re: [cfe-dev] [EXTERNAL] Re: making -ftrivial-auto-var-init=zero a first-class option<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Wed, Apr 22, 2020 at 10:50 AM Joe Bialek via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black">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. 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.<o:p></o:p></span></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><br>
At least in Clang, what powers warnings versus what powers optimizations are quite different - there are lots of things we could trap on that we couldn't warn on. (because the warning would have to describe to the user what codepath was taken, what values were
needed to take those paths, etc - but trap wouldn't)<br>
<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black">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. 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.<o:p></o:p></span></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">This is the thing the folks concerned about "forking the language" are trying to avoid - not wanting that code to be considered correct/OK/not needing of any changes/corrections.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black">Joe<o:p></o:p></span></p>
</div>
<div class="MsoNormal" align="center" style="text-align:center">
<hr size="2" width="98%" align="center">
</div>
<div id="gmail-m_3283834999301420614divRplyFwdMsg">
<p class="MsoNormal"><b><span style="color:black">From:</span></b><span style="color:black"> 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</span>
<o:p></o:p></p>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">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<o:p></o:p></p>
</div>
</div>
</div>
<p class="MsoNormal">_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.llvm.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fcfe-dev&data=02%7C01%7Cjobialek%40microsoft.com%7C3954fcdb3a784f80e5a408d7e6e7f13d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637231756169472859&sdata=DKfkGle1Bj1otbr%2FdfeIyY2cMySiXv1o76mztZm1dcE%3D&reserved=0" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><o:p></o:p></p>
</blockquote>
</div>
</div>
</div>
</body>
</html>