<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">My (possibly not fully informed) understanding of the situation is basically what this commenter said:<div><a href="https://pagure.io/fesco/issue/2020#comment-545782">https://pagure.io/fesco/issue/2020#comment-545782</a><br></div><div>> (llvm doesn't implement e.g. _D_FORTIFY_SOURCE=2 properly)</div><div><br></div><div>As a clang developer, the way I see the issue is that -D_FORTIFY_SOURCE=2 liberally uses GCC extensions. Many changes could be made upstream in glibc to make fortify source work better with clang. Implementing the extensions needed in clang is a bit heroic.</div><div><br></div><div>I just want to push back on the narrative that we "haven't implemented" _FORTIFY_SOURCE. Clang hasn't implemented some collection of hard-to-implement GCC extensions, and </div><div>_FORTIFY_SOURCE happens to depend on them. Many of these extensions are borderline incompatible with fundamental LLVM and Clang design decisions (__builtin_va_arg_pack_len, see <a href="https://clang.llvm.org/docs/UsersManual.html#gcc-extensions-not-implemented-yet">https://clang.llvm.org/docs/UsersManual.html#gcc-extensions-not-implemented-yet</a>), and relaxing them isn't fun or easy. Many contributors are busy doing other security related things, see all the work on shadow call stack, CFI, speculative load hardening, sanitizers, coverage directed fuzzing, etc.</div><div><br></div><div>I also don't think there is clear consensus that _FORTIFY_SOURCE is a valuable mitigation for most codebases. In C++ code, data is in vectors and strings, not stack allocated arrays. It's not immediately clear that _FORTIFY_SOURCE helps with this kind of code. So, for many contributors, it is much lower priority than hardening virtual and indirect calls (CFI).</div><div><br></div><div>Regarding security, I don't think it's a clear cut case that one compiler is "better". The user needs to be able to assess the inherent value of the security mitigations provided by the compiler, and right now the compilers just have different strengths, weaknesses, and depth of integration.</div><div><br></div><div>> and as mentioned above debuginfo issues.<br></div><div><br></div><div>This is a real problem, unfortunately, and it's been fairly well documented in presentations, blog posts, etc. However, I subscribe to the debuginfo project on Phabricator, and I regularly see reviews go by to do the work necessary to improve variable location tracking, so hopefully things will get better.</div></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Feb 19, 2019 at 11:43 AM Sylvestre Ledru via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.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">
<div>
<p>Hello,</p>
<p>Looking at a Fedora thread ( <a class="gmail-m_-6730175664355727237moz-txt-link-freetext" href="https://pagure.io/fesco/issue/2020" target="_blank">https://pagure.io/fesco/issue/2020</a> )
about changing the compiler from gcc to clang to build Firefox,<br>
I noticed the following statement:</p>
<p><span class="gmail-m_-6730175664355727237comment_text gmail-m_-6730175664355727237comment_body">"Clang lags significantly
behind GCC on security hardening"</span></p>
<p>Some of the arguments or missing features are discussed here:<br>
</p>
<p><a class="gmail-m_-6730175664355727237moz-txt-link-freetext" href="https://pagure.io/fesco/issue/2020#comment-546825" target="_blank">https://pagure.io/fesco/issue/2020#comment-546825</a> and other
answers<br>
<a class="gmail-m_-6730175664355727237moz-txt-link-freetext" href="https://pagure.io/fesco/issue/2020#comment-545776" target="_blank">https://pagure.io/fesco/issue/2020#comment-545776</a> <br>
</p>
<p>I am wondering if these statements are accurate and if they are
enough of a worry?</p>
<p>Thanks,<br>
Sylvestre</p>
<p><br>
</p>
</div>
_______________________________________________<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://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote></div>