{"id":273,"date":"2014-04-10T09:51:26","date_gmt":"2014-04-10T09:51:26","guid":{"rendered":"http:\/\/blogs.gentoo.org\/lu_zero\/?p=273"},"modified":"2014-04-10T09:51:26","modified_gmt":"2014-04-10T09:51:26","slug":"security-and-tools","status":"publish","type":"post","link":"https:\/\/blogs.gentoo.org\/lu_zero\/2014\/04\/10\/security-and-tools\/","title":{"rendered":"Security and Tools"},"content":{"rendered":"<blockquote><p>\nEverybody should remember than a 100% secure device is the one unplugged and put in a safe covered in concrete. There is always a trade-off on the impairment we inflict ourselves in order to stay safe.<\/p>\n<footer>\n<cite>Antonio Lioy<\/cite>\n<\/p><\/blockquote>\n<p>In the wake of the <a href=\"http:\/\/heartbleed.com\/\">heartbleed<\/a> bug. I&#8217;d like to return again on what we have to track problems and how they could improve.<\/p>\n<h2>The tools of the trade<\/h2>\n<h3>Memory checkers<\/h3>\n<p>I wrote in many places regarding memory checkers, they are usually a boon and they catch a good deal of issues once coupled with good samples. I managed to fix a good number of issues in <b>hevc<\/b> just by using gcc-asan and running the normal <a href=\"https:\/\/fate.libav.org\">tests<\/a> and for <b>vp9<\/b> took not much time to spot a couple of issues as well (the memory checkers aren&#8217;t perfect so they didn&#8217;t spot the faulty memcpy I introduced to simplify a loop).<\/p>\n<p>If you maintain some software please do use <b>valgrind<\/b>, <b>asan<\/b> (now also available on <b>gcc<\/b>) and, if you are on windows, drmemory. They help you catch bugs early. Just beware that sometimes certain versions of <b>clang-asan<\/b> miscompile. Never blindly trust the tools.<\/p>\n<h3>Static analyzers<\/h3>\n<p>The static analyzers are a mixed bag, sometimes they spot glaring mistakes sometimes they just point at impossible conditions.<br \/>\nPlease do not put asserts to make them happy, if they are right you just traded a faulty memory access for a deny of service.<\/p>\n<h3>Other checkers<\/h3>\n<p>There are plenty other good tools from the <b>*san<\/b> family one can use, ubsan is maybe the newest available in gcc and it does help. Valgrind has plenty as well and the upcoming drmemory has a good deal of interesting perks, if only upstream hadn&#8217;t been so particular with release process and build systems you&#8217;d have it in Gentoo since last year&#8230;<\/p>\n<h3>Regression tests<\/h3>\n<p>I guess everybody is getting sick of me talking about fuzzy testing or why I spent weeks to have a fast regression test archive called <b>playground<\/b> for Libav and I&#8217;m sure everybody in Gentoo is missing the tinderbox runs <a href=\"http:\/\/flameeyes.eu\">Diego<\/a> used to run.<br \/>\nHaving a good and comprehensive batch of checks to make sure new code and new fixes do not have the uncalled side effect of breaking stuff is nice, coupled with <b>git bisect<\/b> makes backporting to fix issues in release branches much easier.<\/p>\n<h3>Debuggers<\/h3>\n<p>We have <b>gdb<\/b>, that works quite well, and we have <b>lldb<\/b> that should improve a lot. And many extensions on top of them. When they fail we can always rely on printf, <b>or not<\/b>&#8230;<\/p>\n<h2>What&#8217;s missing<\/h2>\n<h3>Speed<\/h3>\n<p>If security is just an acceptable impairment over performance in order not to crash, using the tools mentioned are an acceptable slow down on the development process in order not to spend much more time later tracking those issues.<\/p>\n<p>The teams behind <b>valgrind<\/b> and <b>*san<\/b> are doing their best to just make the execution three-four times as slow when the code is instrumented.<\/p>\n<p>The static analyzers are usually just 5 times as slow as a normal compiler run.<\/p>\n<p>A serial regression test run could take ages and in parallel could make your system not able to do anything else.<\/p>\n<p>Any speed up there is a boon. Bigger hardware and automation mitigates the problem.<\/p>\n<h3>Precision<\/h3>\n<p>While <b>gdb<\/b> is already good in getting you information out of gcc-compiled data apparently clang-compiled binaries are a bit harder. Using <b>lldb<\/b> is a subtle form of masochism right now for many reasons, it getting confused is just the icing of a cake of annoyance.<\/p>\n<h3>Integration<\/h3>\n<p>So far is a fair fight between valgrind and *san on which integrates better with the debuggers. I started using asan mostly because made introspecting memory as simple as calling a function from gdb. Valgrind has a richer interface but is a pain to use.<\/p>\n<h3>Reporting<\/h3>\n<p>Some tools are better than other in pointing out the issues. Clang is so far the best with gcc-4.9 coming closer. Most static analyzers are trying their best to deliver the big picture and the detail. gdb so far is incredibly better compared to lldb, but there are already some details in lldb output that gdb should copy.<\/p>\n<h2>Thanks<\/h2>\n<p>I&#8217;m closing this post thanking everybody involved in creating those useful, yet perfectible tools, all the people actually using them and reporting bugs back and everybody actually fixing the mentioned bugs so I don&#8217;t have to do myself alone =)<\/p>\n<p>Everything is broken, but we are fixing most of it together.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Everybody should remember than a 100% secure device is the one unplugged and put in a safe covered in concrete. There is always a trade-off on the impairment we inflict ourselves in order to stay safe. Antonio Lioy In the wake of the heartbleed bug. I&#8217;d like to return again on what we have to &hellip; <a href=\"https:\/\/blogs.gentoo.org\/lu_zero\/2014\/04\/10\/security-and-tools\/\" class=\"more-link\">Continue reading <span class=\"screen-reader-text\">Security and Tools<\/span><\/a><\/p>\n","protected":false},"author":10,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"spay_email":"","jetpack_publicize_message":"","jetpack_is_tweetstorm":false,"jetpack_publicize_feature_enabled":true},"categories":[3,14,6],"tags":[],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/p1aGWH-4p","_links":{"self":[{"href":"https:\/\/blogs.gentoo.org\/lu_zero\/wp-json\/wp\/v2\/posts\/273"}],"collection":[{"href":"https:\/\/blogs.gentoo.org\/lu_zero\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogs.gentoo.org\/lu_zero\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogs.gentoo.org\/lu_zero\/wp-json\/wp\/v2\/users\/10"}],"replies":[{"embeddable":true,"href":"https:\/\/blogs.gentoo.org\/lu_zero\/wp-json\/wp\/v2\/comments?post=273"}],"version-history":[{"count":1,"href":"https:\/\/blogs.gentoo.org\/lu_zero\/wp-json\/wp\/v2\/posts\/273\/revisions"}],"predecessor-version":[{"id":274,"href":"https:\/\/blogs.gentoo.org\/lu_zero\/wp-json\/wp\/v2\/posts\/273\/revisions\/274"}],"wp:attachment":[{"href":"https:\/\/blogs.gentoo.org\/lu_zero\/wp-json\/wp\/v2\/media?parent=273"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.gentoo.org\/lu_zero\/wp-json\/wp\/v2\/categories?post=273"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.gentoo.org\/lu_zero\/wp-json\/wp\/v2\/tags?post=273"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}