[{"id":1778568,"web_url":"http://patchwork.ozlabs.org/comment/1778568/","msgid":"","list_archive_url":null,"date":"2017-10-02T20:11:40","subject":"Re: [RFC][PATCH] Refactoring FORTIFY","submitter":{"id":72344,"url":"http://patchwork.ozlabs.org/api/people/72344/","name":"George Burgess IV","email":"george.burgess.iv@gmail.com"},"content":"Ping. :)\n\n(If I don't get a response after a few more pings, I'll go ahead\nand split this up/try to get it reviewed.)\n\nOn Sun, Sep 10, 2017 at 11:26 PM, George Burgess IV\n wrote:\n> Hello,\n>\n> Attached is a patch that aims to substantially improve FORTIFY's\n> usefulness with clang, and make defining FORTIFY'ed functions require\n> less ceremony.\n>\n> I'm not looking for a thorough review at this time, nor do I hope to\n> land this patch in one piece. The goal of this thread is to ensure\n> that everyone's more or less happy with where I'd like to take glibc's\n> FORTIFY implementation.\n>\n> Please note that this change is intended to be a functional nop for\n> all compilers that aren't clang >= 5.0, which was just released last\n> Thursday.\n>\n> Diving in: as said, this patch removes a lot of duplication from\n> FORTIFY in the common case, and makes FORTIFY far more useful for\n> those who use glibc with clang. Namely, with this patch, clang becomes\n> capable of emitting compile-time diagnostics on par (*) with GCC's,\n> and clang's ability to perform run-time checks is substantially\n> improved over what we have today.\n>\n> It essentially does this by wrapping up the majority of the\n> compiler-specific incantations (declaring __foo_chk_warn,\n> conditionally calling it, ...) behind a macro, and uses that to stamp\n> out FORTIFY's compile-time diagnostic bits. While this approach is the\n> cleanest I've been able to come up with, it has potential downsides:\n>\n> - Compile-time diagnostics with GCC are somewhat different than what\n> they are today. To show this, I've attached tst-chk2-output.diff,\n> which is a diff of the diagnostics produced by running GCC 7.1 on\n> debug/tst-chk2.c. I don't find the difference to be substantial, but\n> it does exist.\n> - In very rare cases, the code generated by GCC will be a bit worse\n> (e.g. slower+larger) with this patch. I know this may be a tough sell,\n> but please hear me out. :)\n>\n> With this patch, we sometimes emit diagnostics by emitting code like:\n> if (should_emit_compile_time_warning) {\n> volatile char c = 0;\n> if (__glibc_unlikely (c))\n> function_with_warnattr ();\n> }\n>\n> Where `should_emit_compile_time_warning` always folds to a constant\n> during compilation. So, 0 diagnostics should mean 0 change in code\n> quality.\n>\n> I don't believe this is a deal-breaker, since:\n> - if you're using FORTIFY, you presumably care enough to fix\n> FORTIFY-related warnings, which makes this regression nonexistent for\n> you,\n> - if you're using FORTIFY, you know there will be a (small, but\n> present) performance penalty,\n> - directly after each __glibc_unlikely(c) branch is call to a FORTIFY\n> function with known broken input, which should abort the program\n> anyway, and\n> - this doesn't apply to *all* diagnostics (e.g. bad calls to open()\n> don't have this penalty); just ones where we can unify clang's and\n> GCC's diagnostic emission bits.\n>\n> In any case, please see binary-output.diff for an idea of the\n> difference this makes on code compiled with GCC 7.1. The function\n> being compiled was a call to wmemmove with an undersized buffer. With\n> a sufficiently large buffer, both today's FORTIFY implementation and\n> the proposed one produce identical bodies for the function in\n> question.\n>\n> Other than that, I know of no regressions that this patch causes with GCC.\n>\n> For clang, in very rare cases (read: I've seen ~10 instances of this\n> testing similar implementations across Android, ChromeOS, and another\n> very large code base), it can also break existing code. For specifics\n> on that, and an overview on how clang's FORTIFY implementation works,\n> please see\n> https://docs.google.com/document/d/1DFfZDICTbL7RqS74wJVIJ-YnjQOj1SaoqfhbgddFYSM/edit?usp=sharing\n> The \"How does clang handle it?\" section covers the primary attributes\n> this patch uses, and the \"Incompatibilities between clang and GCC\n> FORTIFY\" section covers places where this patch might break existing\n> clang users.\n>\n> Though I expect clang breakages to be very rare and trivial to fix,\n> this patch introduces a _CLANG_FORTIFY_DISABLE macro, which can be\n> used to turn this entire patch into a nop for clang >= 5.0.\n>\n> -----\n>\n> I apologize if this is a lot to dump into one email. As said, if we\n> decide this is an acceptable direction to head in, I hope to land this\n> patch in many easily reviewable parts later on.\n>\n> If you have any questions, comments, concerns, etc. please don't\n> hesitate to voice them.\n>\n> Thank you very much for your time, :)\n> George\n>\n> (*) - This means that clang can catch almost as many *types* of bugs\n> as GCC at compile-time. Due to architectural constraints, clang can\n> only perform these checks prior to optimizing code.\n> So, clang is still unable to statically diagnose bugs that require it\n> to do more than simple constant folding. __builtin_object_size,\n> however, isn't required to be folded until after we optimize code, so\n> many dynamic checks can still take advantage of optimizations.","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","mailing list libc-alpha@sourceware.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=sourceware.org\n\t(client-ip=209.132.180.131; helo=sourceware.org;\n\tenvelope-from=libc-alpha-return-85266-incoming=patchwork.ozlabs.org@sourceware.org;\n\treceiver=)","ozlabs.org; dkim=pass (1024-bit key;\n\tsecure) header.d=sourceware.org header.i=@sourceware.org\n\theader.b=\"PuJxVwh6\"; dkim-atps=neutral","sourceware.org; auth=none"],"Received":["from sourceware.org (server1.sourceware.org [209.132.180.131])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3y5YHV5MNlz9s0Z\n\tfor ;\n\tTue, 3 Oct 2017 07:12:38 +1100 (AEDT)","(qmail 89408 invoked by alias); 2 Oct 2017 20:12:30 -0000","(qmail 88165 invoked by uid 89); 2 Oct 2017 20:12:29 -0000"],"DomainKey-Signature":"a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id\n\t:list-unsubscribe:list-subscribe:list-archive:list-post\n\t:list-help:sender:mime-version:in-reply-to:references:from:date\n\t:message-id:subject:to:content-type; q=dns; s=default; b=X2nqYup\n\tAPWbjxRRx+LvdbccJ0+UZyUp/xny3ErfypBmTIXjWzB70mbdsePS+gYN1rsV2VPs\n\t9xjgoi90vNH7R36k5LueTJz6vJsApJM1voZIEOhKuoI9VLopUZMv0/lpKdoa4iKT\n\t2Q4Mnf+6G0Vqp9wjJw8Uw0aphWmTLdDePMnc=","DKIM-Signature":"v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id\n\t:list-unsubscribe:list-subscribe:list-archive:list-post\n\t:list-help:sender:mime-version:in-reply-to:references:from:date\n\t:message-id:subject:to:content-type; s=default; bh=hUNJ583NozDcr\n\t9yGZxpAnRC6r2A=; b=PuJxVwh6cQf+DC7vkk1fzzBiU4x3d+PZ0Ktd6vVvXPLbn\n\tmT+1G5bHARgHsnTHA5Pi9lfm7GP1+/+ALDVnszbwZ95cXgSBR75mtJGD5ApCa+lH\n\tHB/YerKTHRt0DqQD7IyQwLAkIs1ZRLEJzgLUMXmmqtJm0BsVLsfEof73U7BMSc=","Mailing-List":"contact libc-alpha-help@sourceware.org; run by ezmlm","Precedence":"bulk","List-Id":"","List-Unsubscribe":"","List-Subscribe":"","List-Archive":"","List-Post":"","List-Help":",\n\t","Sender":"libc-alpha-owner@sourceware.org","X-Virus-Found":"No","X-Spam-SWARE-Status":"No, score=-7.7 required=5.0 tests=AWL, BAYES_00,\n\tFREEMAIL_FROM, GIT_PATCH_2, RCVD_IN_DNSWL_NONE,\n\tRCVD_IN_SORBS_SPAM,\n\tSPF_PASS autolearn=ham version=3.3.2 spammy=tough,\n\tarchitectural, voice, specifics","X-HELO":"mail-pf0-f180.google.com","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:mime-version:in-reply-to:references:from:date\n\t:message-id:subject:to;\n\tbh=Y8l/HWW+GtE0LxpHlCDUwfcHAJzW6ss/dsYJWB55jv8=;\n\tb=pJ1SLixj0QWvRWr6agbq4OcDy6Vqw+3yghYG0SZ5DuRccwcBM37Px+MXNn+89GdW5X\n\tJtqs0SNUopqJrXseVcMZ+aVTrHxGhlRV2dFjHZ5tLxlTE4xF2zymZ69OhpZUf6hIjdFc\n\tgVhTFmEu65Me/BB3lyKL2Gg2TcuqE+J6QJ4+YaO3SgQYyB9R09kG9z6SDty5n8D/FbsU\n\tVfR2ZbUtMkGobViSPNGU2J5iv+kyPvuHsY8oAIAZfaew2SNOitdA8zdL4uLzF2xgqFg4\n\tVg7GwZGO0oUeWtwv8I9aIBpOLiEktbRZMyqNCnQvzyxZSf7Z/Q+kjT1gCcyLaYKOAOMG\n\the6w==","X-Gm-Message-State":"AHPjjUiJe9AsO9KXeGXyCQ7iV66AWmzH7U3RGKUMEWh4D1KEyGO8uvKi\n\t/JQw2obzXRd6dEUg/OMJb5CDlyybUYTcKBg2LKK2kg==","X-Google-Smtp-Source":"AOwi7QDYFgE6d12oONtw8wD1PCcUu/rXAgWx5BOWNM1uBKt5q0Gq65BBKVhAavnWNQgqxm0f9DmDgjyeoje8kkerE5s=","X-Received":"by 10.159.204.139 with SMTP id\n\tt11mr15189695plo.359.1506975140960; \n\tMon, 02 Oct 2017 13:12:20 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"","References":"","From":"George Burgess IV ","Date":"Mon, 2 Oct 2017 13:11:40 -0700","Message-ID":"","Subject":"Re: [RFC][PATCH] Refactoring FORTIFY","To":"libc-alpha@sourceware.org","Content-Type":"text/plain; charset=\"UTF-8\""}},{"id":1779220,"web_url":"http://patchwork.ozlabs.org/comment/1779220/","msgid":"<9ea2b3d3-c7d0-1d36-db4d-4de7b21067f1@linaro.org>","list_archive_url":null,"date":"2017-10-03T19:34:05","subject":"Re: [RFC][PATCH] Refactoring FORTIFY","submitter":{"id":66065,"url":"http://patchwork.ozlabs.org/api/people/66065/","name":"Adhemerval Zanella Netto","email":"adhemerval.zanella@linaro.org"},"content":"On 11/09/2017 03:26, George Burgess IV wrote:\n> Hello,\n> \n> Attached is a patch that aims to substantially improve FORTIFY's\n> usefulness with clang, and make defining FORTIFY'ed functions require\n> less ceremony.\n\nDue the patch size and complexity and no indication on the message, it\nwould be good to know if you already have a copyright assignment, and\nif your work is covered by it.\n\nYou will need it to sort this out first so someone can actually look\ninto your patch (which I am interested in review btw).","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","mailing list libc-alpha@sourceware.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=sourceware.org\n\t(client-ip=209.132.180.131; helo=sourceware.org;\n\tenvelope-from=libc-alpha-return-85317-incoming=patchwork.ozlabs.org@sourceware.org;\n\treceiver=)","ozlabs.org; dkim=pass (1024-bit key;\n\tsecure) header.d=sourceware.org header.i=@sourceware.org\n\theader.b=\"oZy8fSDa\"; dkim-atps=neutral","sourceware.org; auth=none"],"Received":["from sourceware.org (server1.sourceware.org [209.132.180.131])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3y68Ns61vJz9s83\n\tfor ;\n\tWed, 4 Oct 2017 06:34:21 +1100 (AEDT)","(qmail 83994 invoked by alias); 3 Oct 2017 19:34:13 -0000","(qmail 82341 invoked by uid 89); 3 Oct 2017 19:34:13 -0000"],"DomainKey-Signature":"a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id\n\t:list-unsubscribe:list-subscribe:list-archive:list-post\n\t:list-help:sender:subject:to:references:from:message-id:date\n\t:mime-version:in-reply-to:content-type\n\t:content-transfer-encoding; q=dns; s=default; b=Gnt7V0ihAU3zNyN6\n\t3XIK/2No5ard7jd9gWn19BWjSXNZWVh2XfOcgNDE171bxr/oclrrawjGsRodz/zG\n\tsEyJBC6fOvXGvHK/I72hEvbGRa1Oqxo/HL60yJ9fUC9Rcp+AOi7z4psxs65DASM/\n\txp87hpkLVsNZsbX4NZIbrFNHnYc=","DKIM-Signature":"v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id\n\t:list-unsubscribe:list-subscribe:list-archive:list-post\n\t:list-help:sender:subject:to:references:from:message-id:date\n\t:mime-version:in-reply-to:content-type\n\t:content-transfer-encoding; s=default; bh=ELoKzcfZfBoEJchfEdbi3K\n\tN2moY=; b=oZy8fSDa/k5sDEWyGFAL4VlsSlVlhnqqI+NewhS5a1yy/dfCR8ruRt\n\tP46GEWpstNb84z0Ick00goyUBN6Kbzd52X6oCVVOy//+80VgTWI4t+FUFQx4UwjM\n\tDK374V0bzxlfa5ohy4F8Hc4BBH7xvVQ5ByR/shuRMz2s+QRMBfLLE=","Mailing-List":"contact libc-alpha-help@sourceware.org; run by ezmlm","Precedence":"bulk","List-Id":"","List-Unsubscribe":"","List-Subscribe":"","List-Archive":"","List-Post":"","List-Help":",\n\t","Sender":"libc-alpha-owner@sourceware.org","X-Virus-Found":"No","X-Spam-SWARE-Status":"No, score=-1.4 required=5.0 tests=BAYES_00,\n\tRCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM,\n\tSPF_PASS autolearn=no version=3.3.2 spammy=","X-HELO":"mail-qt0-f180.google.com","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:subject:to:references:from:message-id:date\n\t:user-agent:mime-version:in-reply-to:content-language\n\t:content-transfer-encoding;\n\tbh=FAJJ+iSZVFVa6wlunn4TldenI/R9Pxjw7SZlbZLrqJU=;\n\tb=XzuRbtSO6glYi85uhPhjydv8KU2C4XftFhjj9UHWFbsTDYSYdBj5NcGRj2kvz02X1U\n\tKPInlwGt6LnEI+RO6cGBxzgZCW673iiaXVj7g3cnV9IIG9+CiDMV8EnM1clEAyxmIqsG\n\tkiztVxb7dNljGu3sSSYjXqtsgYsaKtK7EaJj1DGLO7xxRrhOem/UeRXSy5LqTvxwB+mp\n\tqrNKcdo4EACwB9Z3wgSyVQEZ/O6KiLi9JEslk4f9LmhFZ6yy4KlAqrcCIhdWiEJky5aj\n\tjpMVVVnM4Sevyw7oCdyJFLfOteikS3iXwdAJvIed7zB4VRiYKuKBH7KMKTPEywYvlXdh\n\t1QTg==","X-Gm-Message-State":"AMCzsaVK15umJ5XDQHB+O7Zs8Oud5r5hnymjLDQlAJHhESdO5awmVjYt\n\tV5s6ZPKDijVHD+sY4Kcug9j0/RnXj6w=","X-Google-Smtp-Source":"AOwi7QBU41wG9iMIYXGK8WKsD43g78zr0UinL7kZhJKdm0i/3IrX7HzfInWkWZ0M1o1eZpLYgXaKcw==","X-Received":"by 10.200.27.28 with SMTP id y28mr26019114qtj.297.1507059250278; \n\tTue, 03 Oct 2017 12:34:10 -0700 (PDT)","Subject":"Re: [RFC][PATCH] Refactoring FORTIFY","To":"George Burgess IV ,\n\tlibc-alpha@sourceware.org","References":"","From":"Adhemerval Zanella ","Message-ID":"<9ea2b3d3-c7d0-1d36-db4d-4de7b21067f1@linaro.org>","Date":"Tue, 3 Oct 2017 16:34:05 -0300","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.3.0","MIME-Version":"1.0","In-Reply-To":"","Content-Type":"text/plain; charset=utf-8","Content-Transfer-Encoding":"7bit"}},{"id":1779256,"web_url":"http://patchwork.ozlabs.org/comment/1779256/","msgid":"","list_archive_url":null,"date":"2017-10-03T20:53:47","subject":"Re: [RFC][PATCH] Refactoring FORTIFY","submitter":{"id":72344,"url":"http://patchwork.ozlabs.org/api/people/72344/","name":"George Burgess IV","email":"george.burgess.iv@gmail.com"},"content":"I have not signed a copyright assignment yet, though I'm more than\nhappy to do so. Would\nhttp://git.savannah.gnu.org/cgit/gnulib.git/plain/doc/Copyright/request-assign.future\nbe the appropriate form for me to fill out and send in?\n\nIf it changes things, I wrote this as a part of my work with Google,\nwho says they have a CLA on file with the FSF.\n\nThank you,\nGeorge\n\nOn Tue, Oct 3, 2017 at 12:34 PM, Adhemerval Zanella\n wrote:\n> On 11/09/2017 03:26, George Burgess IV wrote:\n>> Hello,\n>>\n>> Attached is a patch that aims to substantially improve FORTIFY's\n>> usefulness with clang, and make defining FORTIFY'ed functions require\n>> less ceremony.\n>\n> Due the patch size and complexity and no indication on the message, it\n> would be good to know if you already have a copyright assignment, and\n> if your work is covered by it.\n>\n> You will need it to sort this out first so someone can actually look\n> into your patch (which I am interested in review btw).","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","mailing list libc-alpha@sourceware.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=sourceware.org\n\t(client-ip=209.132.180.131; helo=sourceware.org;\n\tenvelope-from=libc-alpha-return-85320-incoming=patchwork.ozlabs.org@sourceware.org;\n\treceiver=)","ozlabs.org; dkim=pass (1024-bit key;\n\tsecure) header.d=sourceware.org header.i=@sourceware.org\n\theader.b=\"Sd/vINzC\"; dkim-atps=neutral","sourceware.org; auth=none"],"Received":["from sourceware.org (server1.sourceware.org [209.132.180.131])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3y6B9V0J6qz9sRm\n\tfor ;\n\tWed, 4 Oct 2017 07:54:37 +1100 (AEDT)","(qmail 13292 invoked by alias); 3 Oct 2017 20:54:31 -0000","(qmail 13275 invoked by uid 89); 3 Oct 2017 20:54:31 -0000"],"DomainKey-Signature":"a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id\n\t:list-unsubscribe:list-subscribe:list-archive:list-post\n\t:list-help:sender:mime-version:in-reply-to:references:from:date\n\t:message-id:subject:to:cc:content-type; q=dns; s=default; b=vT6U\n\tfQ+cMI18il4CEt3O033N2lVCAq6YqrGigQmp1BjU2pFHOqefdZjAamAICJNeuKpQ\n\tLaJKI+L9TjStlKS6hkijU/V8Y4qqLONTb45W2yO3htqthQEiifyEjwyGGwr39xIT\n\tGMbZRzW9swIswpjIP8QVrpmpyat6Qc1tYzL3fio=","DKIM-Signature":"v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id\n\t:list-unsubscribe:list-subscribe:list-archive:list-post\n\t:list-help:sender:mime-version:in-reply-to:references:from:date\n\t:message-id:subject:to:cc:content-type; s=default; bh=i7/SAw7iax\n\twZiMl6ylg+83LVA4A=; b=Sd/vINzCLI9dYgqxdr6N00h/GEhmgzb4DOarweHRXT\n\tKkejs1yYGY68pnYfiojpoji9Cfy/LjEUJCxlf8Hp2wUVR+TfkfBOrnAPj8UXVT8v\n\to1e+fyxnROmV2NoO7Fqyxnb/R+r/eso0DetK4M+YxFb08t2Li5wUQnH8cT5Z3ItD\n\tA=","Mailing-List":"contact libc-alpha-help@sourceware.org; run by ezmlm","Precedence":"bulk","List-Id":"","List-Unsubscribe":"","List-Subscribe":"","List-Archive":"","List-Post":"","List-Help":",\n\t","Sender":"libc-alpha-owner@sourceware.org","X-Virus-Found":"No","X-Spam-SWARE-Status":"No, score=-2.7 required=5.0 tests=AWL, BAYES_00,\n\tFREEMAIL_FROM, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM,\n\tSPF_PASS autolearn=no version=3.3.2 spammy=","X-HELO":"mail-pf0-f180.google.com","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:mime-version:in-reply-to:references:from:date\n\t:message-id:subject:to:cc;\n\tbh=gvzYr3jOxuY8wZm+wdx8M53lVtxpUbNcS9NgjMsYoZo=;\n\tb=hX4YcYYPdvB96G4Ameumu+74zVldJvBELk2H8UGE+9zhGAOpWqVIDmQRGy5kS4JLJm\n\tThgk6ve/BH4T/6TjQos3mLj6oXc0AzWss6iOYyUOD99pfX6vJskFwywfM71vfgl882kA\n\tQPgqxq+3CBsjDzqUuU3D3SAi/NccTXEEMqVRTm3lbdN7/0gfc2C0bU1450/UvZQSts+M\n\tb3ZkcVWeNA2+DWeMmbXgQHjx9MPrIkWZMMiz9mohg74qJSqvALahFaX8JhlbM9d5YI3F\n\tNd+0AC5l/DXmHqujIO3egGSbE7TJTwqNU/lMNfDwDYCv3c0EOHPQA2dwlMoAh6KnudLd\n\tcdzA==","X-Gm-Message-State":"AMCzsaU97m5bY3U3Ze/6Bhtcrh5adP89zcrA2Cqv3IWg3d9d4inSmNXz\n\t540vPgs3SM5E7d9D3vgXFKsp2e+6PQAhv4oPqxK6dWKD","X-Google-Smtp-Source":"AOwi7QDDJyMBWsurIPRLGZnmC4V1956M905kYyOdDqKy9+AE9raS7PE65Wl7vdq1eZ1JAxZDgCUaNOXYU9+aH06B4Ag=","X-Received":"by 10.98.109.69 with SMTP id i66mr5725006pfc.200.1507064068213; \n\tTue, 03 Oct 2017 13:54:28 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"<9ea2b3d3-c7d0-1d36-db4d-4de7b21067f1@linaro.org>","References":"\n\t<9ea2b3d3-c7d0-1d36-db4d-4de7b21067f1@linaro.org>","From":"George Burgess IV ","Date":"Tue, 3 Oct 2017 13:53:47 -0700","Message-ID":"","Subject":"Re: [RFC][PATCH] Refactoring FORTIFY","To":"Adhemerval Zanella ","Cc":"libc-alpha@sourceware.org","Content-Type":"text/plain; charset=\"UTF-8\""}},{"id":1780628,"web_url":"http://patchwork.ozlabs.org/comment/1780628/","msgid":"<1e61b1be-d7c3-4a44-5aa9-b8176fa4e7b8@linaro.org>","list_archive_url":null,"date":"2017-10-05T13:43:24","subject":"Re: [RFC][PATCH] Refactoring FORTIFY","submitter":{"id":66065,"url":"http://patchwork.ozlabs.org/api/people/66065/","name":"Adhemerval Zanella Netto","email":"adhemerval.zanella@linaro.org"},"content":"I am not sure if Google has an assignment that cover submission of all\nits engineers. Also, I am not well versed in the requirements for the\nFSF copyright assignment, the only point I have is the GLIBC wiki entry [1].\n\nJoseph, is the wiki updated with latest guidelines and and does Google\ncurrent CLA already cover George work?\n\n[1] https://sourceware.org/glibc/wiki/Contribution%20checklist#FSF_copyright_Assignment\n\nOn 03/10/2017 17:53, George Burgess IV wrote:\n> I have not signed a copyright assignment yet, though I'm more than\n> happy to do so. Would\n> http://git.savannah.gnu.org/cgit/gnulib.git/plain/doc/Copyright/request-assign.future\n> be the appropriate form for me to fill out and send in?\n> \n> If it changes things, I wrote this as a part of my work with Google,\n> who says they have a CLA on file with the FSF.\n> \n> Thank you,\n> George\n> \n> On Tue, Oct 3, 2017 at 12:34 PM, Adhemerval Zanella\n> wrote:\n>> On 11/09/2017 03:26, George Burgess IV wrote:\n>>> Hello,\n>>>\n>>> Attached is a patch that aims to substantially improve FORTIFY's\n>>> usefulness with clang, and make defining FORTIFY'ed functions require\n>>> less ceremony.\n>>\n>> Due the patch size and complexity and no indication on the message, it\n>> would be good to know if you already have a copyright assignment, and\n>> if your work is covered by it.\n>>\n>> You will need it to sort this out first so someone can actually look\n>> into your patch (which I am interested in review btw).","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","mailing list libc-alpha@sourceware.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=sourceware.org\n\t(client-ip=209.132.180.131; helo=sourceware.org;\n\tenvelope-from=libc-alpha-return-85436-incoming=patchwork.ozlabs.org@sourceware.org;\n\treceiver=)","ozlabs.org; dkim=pass (1024-bit key;\n\tsecure) header.d=sourceware.org header.i=@sourceware.org\n\theader.b=\"UE1sIWJw\"; dkim-atps=neutral","sourceware.org; auth=none"],"Received":["from sourceware.org (server1.sourceware.org [209.132.180.131])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3y7DWH72pkz9sRq\n\tfor ;\n\tFri, 6 Oct 2017 00:43:39 +1100 (AEDT)","(qmail 120629 invoked by alias); 5 Oct 2017 13:43:34 -0000","(qmail 120616 invoked by uid 89); 5 Oct 2017 13:43:33 -0000"],"DomainKey-Signature":"a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id\n\t:list-unsubscribe:list-subscribe:list-archive:list-post\n\t:list-help:sender:subject:to:cc:references:from:message-id:date\n\t:mime-version:in-reply-to:content-type\n\t:content-transfer-encoding; q=dns; s=default; b=Wq3QYZILpMfoAtY2\n\tUcfdG68i32iAAjP9hJczkUNEmWozfQwkWNj90AVNXGv07qWedwcWSABYPwdfLU90\n\tGivivdnX2FIW9OQG2JMIvdJM1Skv+42w2IlHhMJNHEpw6tM/fDOjIl9X4Mpewk2h\n\txE6VzBypUCPthTUetnHL2Qw/0bQ=","DKIM-Signature":"v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id\n\t:list-unsubscribe:list-subscribe:list-archive:list-post\n\t:list-help:sender:subject:to:cc:references:from:message-id:date\n\t:mime-version:in-reply-to:content-type\n\t:content-transfer-encoding; s=default; bh=StlKIopQUISBFxf+lY64Gs\n\tHy0MQ=; b=UE1sIWJwBAlvR1GO2+1fyYRIf6vif+gLmL0UkggPFRCAIDCwnI4qLN\n\t+A3+1lsaBILowzOMHi+4r4S/lhj/8hRKcsaAdFNd0Wa6n/l/pps2XCiPnsRKGnhg\n\tjm6H3xt7Cf2CZT5U6RzMiYc4MLH27bz7IUZXWCBNg6am10YxiYJzo=","Mailing-List":"contact libc-alpha-help@sourceware.org; run by ezmlm","Precedence":"bulk","List-Id":"","List-Unsubscribe":"","List-Subscribe":"","List-Archive":"","List-Post":"","List-Help":",\n\t","Sender":"libc-alpha-owner@sourceware.org","X-Virus-Found":"No","X-Spam-SWARE-Status":"No, score=-1.4 required=5.0 tests=BAYES_00,\n\tRCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM,\n\tSPF_PASS autolearn=no version=3.3.2 spammy=contribution","X-HELO":"mail-qt0-f171.google.com","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:subject:to:cc:references:from:message-id:date\n\t:user-agent:mime-version:in-reply-to:content-language\n\t:content-transfer-encoding;\n\tbh=RYByxpRXQg9iDgfS8MbyNJPSez+uVKu8eDKRmG1mrEE=;\n\tb=lNt/lX+jeIOA0chx4+sp8v2bME0kin3QxZai7P9CDu83lkDOCNuVRyVdxb0Nt2yRRX\n\tBMP7g8Q3LAnXybvRI/iRWuAZo1OWLoMZvwaP3f3678QtmddZ5mMkeDKMspGuF8LR8RAZ\n\t2HOsQefcXlbuxv9yw6eHaLSujia7PoffOlJ/islsoRFU1yojFtYyDnh4dOhGkC+Aex+D\n\tMSYkj/RjMdcuEHvENB06UeUcLY5ZxhaJ9hTKvuXM6uPNaSMrx9AOvYT/db213wXGrcxO\n\tVneJ21ANbInZuUHDP1A9WeaRlXK1UDJJ0Z5CFAW9WcuiSB+qwnoiz3c1SR94/7jVPglc\n\tD8oA==","X-Gm-Message-State":"AMCzsaVslEgtbmp+GCeApDwEQojv+wUv58fsWyEe8N88UZppa1+0UzHM\n\t26KB5vQ9gdNZ2cemBAF/txuNU8fvx70=","X-Google-Smtp-Source":"AOwi7QAJbJdVV6nULeqIh+KiiLeXx1rp18onpPI8nklSfgcGRM2y9RvJyO61gbS4L1grkogzbwrAIQ==","X-Received":"by 10.237.53.212 with SMTP id d20mr14600007qte.10.1507211009883; \n\tThu, 05 Oct 2017 06:43:29 -0700 (PDT)","Subject":"Re: [RFC][PATCH] Refactoring FORTIFY","To":"George Burgess IV ,\n\tJoseph Myers ","Cc":"libc-alpha@sourceware.org","References":"\n\t<9ea2b3d3-c7d0-1d36-db4d-4de7b21067f1@linaro.org>\n\t","From":"Adhemerval Zanella ","Message-ID":"<1e61b1be-d7c3-4a44-5aa9-b8176fa4e7b8@linaro.org>","Date":"Thu, 5 Oct 2017 10:43:24 -0300","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.3.0","MIME-Version":"1.0","In-Reply-To":"","Content-Type":"text/plain; charset=utf-8","Content-Transfer-Encoding":"7bit"}},{"id":1780742,"web_url":"http://patchwork.ozlabs.org/comment/1780742/","msgid":"","list_archive_url":null,"date":"2017-10-05T15:48:22","subject":"Re: [RFC][PATCH] Refactoring FORTIFY","submitter":{"id":4349,"url":"http://patchwork.ozlabs.org/api/people/4349/","name":"Joseph Myers","email":"joseph@codesourcery.com"},"content":"On Thu, 5 Oct 2017, Adhemerval Zanella wrote:\n\n> I am not sure if Google has an assignment that cover submission of all\n> its engineers. Also, I am not well versed in the requirements for the\n> FSF copyright assignment, the only point I have is the GLIBC wiki entry [1].\n> \n> Joseph, is the wiki updated with latest guidelines and and does Google\n> current CLA already cover George work?\n\nThere is a Google assignment dated 2007-03-15 for all GNU projects.\n\nI presume that the Google-internal version of \nhttps://opensource.google.com/docs/patching/ mentions the FSF assignment \nand deals with any Google-specific contribution requirements.","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","mailing list libc-alpha@sourceware.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=sourceware.org\n\t(client-ip=209.132.180.131; helo=sourceware.org;\n\tenvelope-from=libc-alpha-return-85459-incoming=patchwork.ozlabs.org@sourceware.org;\n\treceiver=)","ozlabs.org; dkim=pass (1024-bit key;\n\tsecure) header.d=sourceware.org header.i=@sourceware.org\n\theader.b=\"WmDBVxXp\"; dkim-atps=neutral","sourceware.org; auth=none"],"Received":["from sourceware.org (server1.sourceware.org [209.132.180.131])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3y7HHb59hKz9sNc\n\tfor ;\n\tFri, 6 Oct 2017 02:48:43 +1100 (AEDT)","(qmail 19662 invoked by alias); 5 Oct 2017 15:48:35 -0000","(qmail 16514 invoked by uid 89); 5 Oct 2017 15:48:33 -0000"],"DomainKey-Signature":"a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id\n\t:list-unsubscribe:list-subscribe:list-archive:list-post\n\t:list-help:sender:date:from:to:cc:subject:in-reply-to:message-id\n\t:references:mime-version:content-type; q=dns; s=default; b=CuuhY\n\thrbX1/8V8zrqKxS/Tr8c0tVnTGXViN6+vQZpRslTfQXx944U6k7PN90gXLzVqIEv\n\tCrCVlJ65Frk68XXhbhki8BZulWvo+eIz6x+6RsCFXLj3KtkioaxA0e3hMTSip2pe\n\tj+atF90fMXjImxE1tWuVEixQLvoeloi5N+9/5E=","DKIM-Signature":"v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id\n\t:list-unsubscribe:list-subscribe:list-archive:list-post\n\t:list-help:sender:date:from:to:cc:subject:in-reply-to:message-id\n\t:references:mime-version:content-type; s=default; bh=zSmCByr6kLN\n\tDoX0G7hjRmQoJ2a4=; b=WmDBVxXpeykjJdwkUqPGOw1QssEfGt129TZHOnAGl3+\n\tpN2CDRCQaU+voD1Kf+o1FUZhp77EKkIXFrmsAJeNWdJG5Q8BfayLcXoh9A5tOnEM\n\th3XG47N8Czu/hKq+QMLNfMCJPUd4f49IyECzb+2xZgvQx1gIK1qqXWwgOTW+SEtw\n\t=","Mailing-List":"contact libc-alpha-help@sourceware.org; run by ezmlm","Precedence":"bulk","List-Id":"","List-Unsubscribe":"","List-Subscribe":"","List-Archive":"","List-Post":"","List-Help":",\n\t","Sender":"libc-alpha-owner@sourceware.org","X-Virus-Found":"No","X-Spam-SWARE-Status":"No, score=-2.0 required=5.0 tests=AWL, BAYES_00,\n\tRCVD_IN_DNSWL_NONE, SPF_PASS,\n\tURIBL_RED autolearn=ham version=3.3.2 spammy=deals, dated","X-HELO":"relay1.mentorg.com","Date":"Thu, 5 Oct 2017 15:48:22 +0000","From":"Joseph Myers ","To":"Adhemerval Zanella ","CC":"George Burgess IV ,\n\t","Subject":"Re: [RFC][PATCH] Refactoring FORTIFY","In-Reply-To":"<1e61b1be-d7c3-4a44-5aa9-b8176fa4e7b8@linaro.org>","Message-ID":"","References":"\n\t<9ea2b3d3-c7d0-1d36-db4d-4de7b21067f1@linaro.org>\n\t\n\t<1e61b1be-d7c3-4a44-5aa9-b8176fa4e7b8@linaro.org>","User-Agent":"Alpine 2.20 (DEB 67 2015-01-07)","MIME-Version":"1.0","Content-Type":"text/plain; charset=\"US-ASCII\"","X-ClientProxiedBy":"svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) To\n\tsvr-ies-mbx-01.mgc.mentorg.com (139.181.222.1)"}},{"id":1780963,"web_url":"http://patchwork.ozlabs.org/comment/1780963/","msgid":"<1B58D4F8-1CE9-4621-A6B7-DC95D1EF284F@linaro.org>","list_archive_url":null,"date":"2017-10-05T20:06:33","subject":"Re: [RFC][PATCH] Refactoring FORTIFY","submitter":{"id":66065,"url":"http://patchwork.ozlabs.org/api/people/66065/","name":"Adhemerval Zanella Netto","email":"adhemerval.zanella@linaro.org"},"content":"Thanks for the follow up, I think we are good regarding it. \n\n> Il giorno 05 ott 2017, alle ore 12:48, Joseph Myers ha scritto:\n> \n>> On Thu, 5 Oct 2017, Adhemerval Zanella wrote:\n>> \n>> I am not sure if Google has an assignment that cover submission of all\n>> its engineers. Also, I am not well versed in the requirements for the\n>> FSF copyright assignment, the only point I have is the GLIBC wiki entry [1].\n>> \n>> Joseph, is the wiki updated with latest guidelines and and does Google\n>> current CLA already cover George work?\n> \n> There is a Google assignment dated 2007-03-15 for all GNU projects.\n> \n> I presume that the Google-internal version of \n> https://opensource.google.com/docs/patching/ mentions the FSF assignment \n> and deals with any Google-specific contribution requirements.\n> \n> -- \n> Joseph S. Myers\n> joseph@codesourcery.com","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","mailing list libc-alpha@sourceware.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=sourceware.org\n\t(client-ip=209.132.180.131; helo=sourceware.org;\n\tenvelope-from=libc-alpha-return-85486-incoming=patchwork.ozlabs.org@sourceware.org;\n\treceiver=)","ozlabs.org; dkim=pass (1024-bit key;\n\tsecure) header.d=sourceware.org header.i=@sourceware.org\n\theader.b=\"Et6wgw3T\"; dkim-atps=neutral","sourceware.org; auth=none"],"Received":["from sourceware.org (server1.sourceware.org [209.132.180.131])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3y7P1M4mTLz9t48\n\tfor ;\n\tFri, 6 Oct 2017 07:06:47 +1100 (AEDT)","(qmail 4047 invoked by alias); 5 Oct 2017 20:06:41 -0000","(qmail 4029 invoked by uid 89); 5 Oct 2017 20:06:41 -0000"],"DomainKey-Signature":"a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id\n\t:list-unsubscribe:list-subscribe:list-archive:list-post\n\t:list-help:sender:content-type:mime-version:subject:from\n\t:in-reply-to:date:cc:content-transfer-encoding:message-id\n\t:references:to; q=dns; s=default; b=lNgVdvi+ATnARnR5ziuAcYR96Ct2\n\twuEf+WHAPePWelDnzY5iE0gOAokwryOsWRgBqe3xTwnVSFYlheteeLJG0yS16V6z\n\txSZZH9H2ym6s38kOc2VgwSAc3pKnxcc71Y7jgOTpWo1fEHkN1Y9j2Dl51KJlVA2c\n\tuNWeWcHlO6h5+Jg=","DKIM-Signature":"v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id\n\t:list-unsubscribe:list-subscribe:list-archive:list-post\n\t:list-help:sender:content-type:mime-version:subject:from\n\t:in-reply-to:date:cc:content-transfer-encoding:message-id\n\t:references:to; s=default; bh=USFy+3kwlk3N2Wl3uaygXDYlc7E=; b=Et\n\t6wgw3TxXTFECjzU2vf+bwJTgOOxG53pdf0VsU64EpRL9vGnGup6hhoLANKRuxGff\n\t0hxDSEU9DbIz4c++b4H+7gyHvwf/m3ggz1iZs4SECqMSlTb3LoXcsYjc/iNrVgRX\n\tpURTDR5nB7vCFWiwI3yZ/ktge1vtNiuM8GAsVjaOs=","Mailing-List":"contact libc-alpha-help@sourceware.org; run by ezmlm","Precedence":"bulk","List-Id":"","List-Unsubscribe":"","List-Subscribe":"","List-Archive":"","List-Post":"","List-Help":",\n\t","Sender":"libc-alpha-owner@sourceware.org","X-Virus-Found":"No","X-Spam-SWARE-Status":"No, score=-1.4 required=5.0 tests=BAYES_00,\n\tRCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM, SPF_PASS,\n\tURIBL_RED autolearn=no version=3.3.2 spammy=H*x:iPhone,\n\tH*UA:iPhone","X-HELO":"mail-qt0-f172.google.com","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc\n\t:content-transfer-encoding:message-id:references:to;\n\tbh=nsppj2LhokOUwD7wYchg3YUK/C9cRtExtrabYhGzCww=;\n\tb=MZv9ic6iS/dzjvNI9IlF9cTWZNJKgDGtgA9rCkXfqud36+a7Yb/Qkehna8VboIA/ZZ\n\tIPH28QNAHZyrODVVpdMb6T9ZAKxIzkHG5PFY4CHiS7CFURXpGCnx4DVEfPRXErLI8w/j\n\tTljCHsrSmJtgYPm5EJrCWNZLikoMSjL3wuGO6qhgGGqvw1Et7TmXQv2OBW6jLj5xbYQH\n\tc1qmk2QKt/Lq4UuMxBqx5KkQx2QN6mLrE/Z+ZGnN+gRtgoODPCuSVWjHirzJpQ9ke8AU\n\t+Wl3wUCrrJkyuGI2GOpI9/+KdJfd7zhgkO+HzUjFGL+bPIkg+dy6n4FHalKEbrsbduft\n\tATDw==","X-Gm-Message-State":"AMCzsaUm7AD/mk1fc7ALEFtXW/RtrJZVekEQQDhsiX0tIoyIOYIOkjdf\n\thKDvyGMUbPT8cQRNVimgSXNJ6aPKJbE=","X-Google-Smtp-Source":"AOwi7QAx6ZOkO9PIA9FEdwvhyUsgxYDJq+ooP0l8K10ZU99/Auf0+IMj74cOJ+TB4qUFe7cpty/79A==","X-Received":"by 10.200.40.142 with SMTP id i14mr35804700qti.326.1507233998385;\n\tThu, 05 Oct 2017 13:06:38 -0700 (PDT)","Content-Type":"text/plain;\n\tcharset=us-ascii","Mime-Version":"1.0 (1.0)","Subject":"Re: [RFC][PATCH] Refactoring FORTIFY","From":"Adhemerval Zanella ","In-Reply-To":"","Date":"Thu, 5 Oct 2017 17:06:33 -0300","Cc":"George Burgess IV ,\n\tlibc-alpha@sourceware.org","Content-Transfer-Encoding":"quoted-printable","Message-Id":"<1B58D4F8-1CE9-4621-A6B7-DC95D1EF284F@linaro.org>","References":"\n\t<9ea2b3d3-c7d0-1d36-db4d-4de7b21067f1@linaro.org>\n\t\n\t<1e61b1be-d7c3-4a44-5aa9-b8176fa4e7b8@linaro.org>\n\t","To":"Joseph Myers "}},{"id":1799925,"web_url":"http://patchwork.ozlabs.org/comment/1799925/","msgid":"","list_archive_url":null,"date":"2017-11-06T19:11:37","subject":"Re: [RFC][PATCH] Refactoring FORTIFY","submitter":{"id":72344,"url":"http://patchwork.ozlabs.org/api/people/72344/","name":"George Burgess IV","email":"george.burgess.iv@gmail.com"},"content":"Ping :)\n\n> I think we are good regarding it\n\nGlad to hear it!\n\nOn Thu, Oct 5, 2017 at 1:06 PM, Adhemerval Zanella\n wrote:\n> Thanks for the follow up, I think we are good regarding it.\n>\n>> Il giorno 05 ott 2017, alle ore 12:48, Joseph Myers ha scritto:\n>>\n>>> On Thu, 5 Oct 2017, Adhemerval Zanella wrote:\n>>>\n>>> I am not sure if Google has an assignment that cover submission of all\n>>> its engineers. Also, I am not well versed in the requirements for the\n>>> FSF copyright assignment, the only point I have is the GLIBC wiki entry [1].\n>>>\n>>> Joseph, is the wiki updated with latest guidelines and and does Google\n>>> current CLA already cover George work?\n>>\n>> There is a Google assignment dated 2007-03-15 for all GNU projects.\n>>\n>> I presume that the Google-internal version of\n>> https://opensource.google.com/docs/patching/ mentions the FSF assignment\n>> and deals with any Google-specific contribution requirements.\n>>\n>> --\n>> Joseph S. Myers\n>> joseph@codesourcery.com","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","mailing list libc-alpha@sourceware.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=sourceware.org\n\t(client-ip=209.132.180.131; helo=sourceware.org;\n\tenvelope-from=libc-alpha-return-86826-incoming=patchwork.ozlabs.org@sourceware.org;\n\treceiver=)","ozlabs.org; dkim=pass (1024-bit key;\n\tsecure) header.d=sourceware.org header.i=@sourceware.org\n\theader.b=\"gbF981Uu\"; dkim-atps=neutral","sourceware.org; auth=none"],"Received":["from sourceware.org (server1.sourceware.org [209.132.180.131])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3yW2Hx1nhmz9s7B\n\tfor ;\n\tTue, 7 Nov 2017 06:12:29 +1100 (AEDT)","(qmail 102956 invoked by alias); 6 Nov 2017 19:12:21 -0000","(qmail 102843 invoked by uid 89); 6 Nov 2017 19:12:21 -0000"],"DomainKey-Signature":"a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id\n\t:list-unsubscribe:list-subscribe:list-archive:list-post\n\t:list-help:sender:mime-version:in-reply-to:references:from:date\n\t:message-id:subject:to:cc:content-type; q=dns; s=default; b=JvZD\n\tvJJtq9yOItDpWsfr/TY3HgTM3L1BK2GaCqCV+LuOkM1NxQYJK+RGvnzWCh06KZDS\n\tAr7LLzMrhVFOs6LUcKqBl/KNtaJSbIimaMo0x9U1YN/cQKGKX/9azopdIXH/gH9J\n\tIkYi/XYUEO8tA6riIkz1IW6ClUAJC+UzmR1y1iw=","DKIM-Signature":"v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id\n\t:list-unsubscribe:list-subscribe:list-archive:list-post\n\t:list-help:sender:mime-version:in-reply-to:references:from:date\n\t:message-id:subject:to:cc:content-type; s=default; bh=pz/h4aJD6W\n\tRK/RzST54C+AGJYRI=; b=gbF981Uudpxc1Q9Ji8pC+0ytpIU06dITCilfl+YVU6\n\t5rQmk1/qxRqfmOnZHhuKhV1dnVRVNMyNG7tNt+sDo2AeOfu9nZNAJ9egO+tLZ+7e\n\tHMHTbqFsI2Q5fhSzk/DdYxwHvnohEXWfgA9YXu6ZuX6UfYCR2WcObyCvPXAFGn7P\n\tU=","Mailing-List":"contact libc-alpha-help@sourceware.org; run by ezmlm","Precedence":"bulk","List-Id":"","List-Unsubscribe":"","List-Subscribe":"","List-Archive":"","List-Post":"","List-Help":",\n\t","Sender":"libc-alpha-owner@sourceware.org","X-Virus-Found":"No","X-Spam-SWARE-Status":"No, score=-1.9 required=5.0 tests=BAYES_00,\n\tFREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_PASS,\n\tURIBL_RED autolearn=ham version=3.3.2 spammy=cla, versed,\n\tengineers, hear","X-HELO":"mail-pg0-f53.google.com","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:mime-version:in-reply-to:references:from:date\n\t:message-id:subject:to:cc;\n\tbh=B4ZjVUa3HyWnKINIr+DEb0wbrK3IMiNkdC+F7kC7978=;\n\tb=phQ4nRQALDH2Ae+/2WHejqhwJE5w8vE7oRl/aph4/2gjzMIz24GW08uFW/ca5gV81b\n\taZJ9XL4c4w+Fg27iPPxfLp2nQp6Wfvsxniw2MhVEqY4ZX7dcOahvPlqurYePDnDNkpwt\n\tiW2Ow9G1KN0FHUEg3+p7bYJ6fLNLIBsL/9z9victVsuJ3XLkwLGcmqFZD1r4LdLoM8BM\n\tdmbgX99OA1OYyhiC8VOEppWWIJu4ADHi3sei6SQsqGi6As9E4MvIPr+togQ6F97aiw6l\n\tqFK4qKMd7UQd33xDy0M0ooNrKZyBEqojS47UhHqQeveY3ROuxHoR5SCFPYSLLvjxCwXA\n\tHfCA==","X-Gm-Message-State":"AMCzsaXoZgixChHVDGxmjM3Ewh2CNkfQk9f5X9WGzWiRuPoCUm/XYJmR\n\tp/XuqiMvkdhbsji+DqIeYlU5eyTyoQDSjJIehDkz3Q==","X-Google-Smtp-Source":"ABhQp+TnyG/47aX65dlvpWGaIhb22lSdZ8JbD39VdsYESSsaXxJSNO1nCNgYgK7rS9ZoYFEdloHSttchAF71jZ8o0WU=","X-Received":"by 10.159.241.129 with SMTP id s1mr15428692plr.378.1509995537641;\n\tMon, 06 Nov 2017 11:12:17 -0800 (PST)","MIME-Version":"1.0","In-Reply-To":"<1B58D4F8-1CE9-4621-A6B7-DC95D1EF284F@linaro.org>","References":"\n\t<9ea2b3d3-c7d0-1d36-db4d-4de7b21067f1@linaro.org>\n\t\n\t<1e61b1be-d7c3-4a44-5aa9-b8176fa4e7b8@linaro.org>\n\t\n\t<1B58D4F8-1CE9-4621-A6B7-DC95D1EF284F@linaro.org>","From":"George Burgess IV ","Date":"Mon, 6 Nov 2017 11:11:37 -0800","Message-ID":"","Subject":"Re: [RFC][PATCH] Refactoring FORTIFY","To":"Adhemerval Zanella ","Cc":"Joseph Myers , libc-alpha@sourceware.org","Content-Type":"text/plain; charset=\"UTF-8\""}},{"id":1807666,"web_url":"http://patchwork.ozlabs.org/comment/1807666/","msgid":"<41677d63-4cec-e24b-e4b7-378aa030a0f7@linaro.org>","list_archive_url":null,"date":"2017-11-20T20:03:28","subject":"Re: [RFC][PATCH] Refactoring FORTIFY","submitter":{"id":66065,"url":"http://patchwork.ozlabs.org/api/people/66065/","name":"Adhemerval Zanella Netto","email":"adhemerval.zanella@linaro.org"},"content":"On 11/09/2017 03:26, George Burgess IV wrote:\n> Hello,\n> \n> Attached is a patch that aims to substantially improve FORTIFY's\n> usefulness with clang, and make defining FORTIFY'ed functions require\n> less ceremony.\n> \n> I'm not looking for a thorough review at this time, nor do I hope to\n> land this patch in one piece. The goal of this thread is to ensure\n> that everyone's more or less happy with where I'd like to take glibc's\n> FORTIFY implementation.\n\nThanks for the patch and patience. The idea sound reasonable and it will\nbe indeed a good addition to extend fortify functionality to clang as well.\n\n> \n> Please note that this change is intended to be a functional nop for\n> all compilers that aren't clang >= 5.0, which was just released last\n> Thursday.\n\nAs a potential side note it would be good to add some short explanation\nof the internal required to adjust it for clang, for instance that\n__use_clang_fortify is a compiler defined flag which is (?) define only\nfor clang 5.0 or higher. In any case the document referenced is a good\naddition for explanation, but I usually prefer to have a more self\nexplanatory detail on the thread and or email itself.\n\n> \n> Diving in: as said, this patch removes a lot of duplication from\n> FORTIFY in the common case, and makes FORTIFY far more useful for\n> those who use glibc with clang. Namely, with this patch, clang becomes\n> capable of emitting compile-time diagnostics on par (*) with GCC's,\n> and clang's ability to perform run-time checks is substantially\n> improved over what we have today.\n> \n> It essentially does this by wrapping up the majority of the\n> compiler-specific incantations (declaring __foo_chk_warn,\n> conditionally calling it, ...) behind a macro, and uses that to stamp\n> out FORTIFY's compile-time diagnostic bits. While this approach is the\n> cleanest I've been able to come up with, it has potential downsides:\n> \n> - Compile-time diagnostics with GCC are somewhat different than what\n> they are today. To show this, I've attached tst-chk2-output.diff,\n> which is a diff of the diagnostics produced by running GCC 7.1 on\n> debug/tst-chk2.c. I don't find the difference to be substantial, but\n> it does exist.\n\nTaking your provided file as an example I do not see it as blocker\nfor this approach. Although the new warning prints the macros used\nto parametrize the builtins invocation, I think it still shows enough\ninformation for debugging. For instance:\n\n-../libio/bits/stdio2.h:64:10: warning: ‘__builtin___snprintf_chk’: specified bound 3 exceeds the size 2 of the destination [-Wstringop-overflow=]\n- return __builtin___snprintf_chk (__s, __n, __USE_FORTIFY_LEVEL - 1,\n- ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n- __bos (__s), __fmt, __va_arg_pack ());\n- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n+../libio/bits/stdio2.h:79:7: warning: ‘__builtin___snprintf_chk’: specified bound 3 exceeds the size 2 of the destination [-Wstringop-overflow=]\n+ int __result = __FORTIFY_CALL_VA_BUILTIN (snprintf, __s, __n,\n\nAlso, some seems more convoluted as:\n\n In function ‘wmemmove’,\n inlined from ‘do_test’ at tst-chk1.c:681:3:\n-../wcsmbs/bits/wchar2.h:77:9: warning: call to ‘__wmemmove_chk_warn’ declared with attribute warning: wmemmove called with length bigger than size of destination buffer\n- return __wmemmove_chk_warn (__s1, __s2, __n,\n- ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n- __bos0 (__s1) / sizeof (wchar_t));\n- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n+../wcsmbs/bits/wchar2.h:56:42: warning: call to ‘__wmemmove_warn’ declared with attribute warning: wmemmove called with length bigger than size of destination buffer\n+ __FORTIFY_WARNING_ONLY_IF_BOS0_LT2 (__wmemmove_warn, __n, __s1,\n+../misc/sys/cdefs.h:234:5: note: in definition of macro ‘__FORTIFY_WARNING_ONLY_IF_BOS0_LT2’\n+ err_fn (); \\\n+ ^~~~~~\n\nWhich might trigger an warning with different internal names being used\nand also with a more convoluted warning which points to an internal name\ninstead direct to a builtin. I still think this is non blocker since\nthe warning is still meaningful and correct to point the api usage issue.\n\n> - In very rare cases, the code generated by GCC will be a bit worse\n> (e.g. slower+larger) with this patch. I know this may be a tough sell,\n> but please hear me out. :)\n> \n> With this patch, we sometimes emit diagnostics by emitting code like:\n> if (should_emit_compile_time_warning) {\n> volatile char c = 0;\n> if (__glibc_unlikely (c))\n> function_with_warnattr ();\n> }\n> \n> Where `should_emit_compile_time_warning` always folds to a constant\n> during compilation. So, 0 diagnostics should mean 0 change in code\n> quality.\n> \n> I don't believe this is a deal-breaker, since:\n> - if you're using FORTIFY, you presumably care enough to fix\n> FORTIFY-related warnings, which makes this regression nonexistent for\n> you,\n> - if you're using FORTIFY, you know there will be a (small, but\n> present) performance penalty,\n> - directly after each __glibc_unlikely(c) branch is call to a FORTIFY\n> function with known broken input, which should abort the program\n> anyway, and\n> - this doesn't apply to *all* diagnostics (e.g. bad calls to open()\n> don't have this penalty); just ones where we can unify clang's and\n> GCC's diagnostic emission bits.\n\nI also agree potential pessimization on code that triggers the fortify\nchecks is not really a blocker. The only issue I would consider for\nit would be if hot path for fortified code also get slower/larger,\nbut it does not seem to be the case. \n\n> \n> In any case, please see binary-output.diff for an idea of the\n> difference this makes on code compiled with GCC 7.1. The function\n> being compiled was a call to wmemmove with an undersized buffer. With\n> a sufficiently large buffer, both today's FORTIFY implementation and\n> the proposed one produce identical bodies for the function in\n> question.\n> \n> Other than that, I know of no regressions that this patch causes with GCC.\n> \n> For clang, in very rare cases (read: I've seen ~10 instances of this\n> testing similar implementations across Android, ChromeOS, and another\n> very large code base), it can also break existing code. For specifics\n> on that, and an overview on how clang's FORTIFY implementation works,\n> please see\n> https://docs.google.com/document/d/1DFfZDICTbL7RqS74wJVIJ-YnjQOj1SaoqfhbgddFYSM/edit?usp=sharing\n\nFor 'Incompatibilities between clang and GCC FORTIFY' chapter in your\ndocumentation, the first one I do not see really an issue because\nrelying on compiler constant fold strlen is quite fragile. The second\none seem more a minor issue, but the a compiler details for a very\nspecialized usage. I do not have a strong opinion if they should be\nused as blockers.\n\n> The \"How does clang handle it?\" section covers the primary attributes\n> this patch uses, and the \"Incompatibilities between clang and GCC\n> FORTIFY\" section covers places where this patch might break existing\n> clang users.\n> \n> Though I expect clang breakages to be very rare and trivial to fix,\n> this patch introduces a _CLANG_FORTIFY_DISABLE macro, which can be\n> used to turn this entire patch into a nop for clang >= 5.0.\n\nI really want to avoid a compiler specific flag to deactivate fortify\nwhere there is already in place better approach (either adjusting\nthe code or disabling fortify). Also it means it would need to to\ncontinue export such macro to maintain compatibility, which also adds\na lot of complexity with no so straightforward gains.\n\n> \n> -----\n> \n> I apologize if this is a lot to dump into one email. As said, if we\n> decide this is an acceptable direction to head in, I hope to land this\n> patch in many easily reviewable parts later on.\n\nIndeed to move forward on review we will need to split this patch by\nfamily functions, maybe an initial patch to add the required macros\nand gcc required refactoring and other for family of functions or\nby headers with the adjustments for clang.\n\nThe only issue I see is lacking of testing I do not have an easier\nsolution. One option would to try check for clang with support for\nfortify on path and add extra rules for build the fortify tests\nwith clang as well, but I am not sure how complex would be to adjust\ncurrent testcase for such scenario.\n\n> \n> If you have any questions, comments, concerns, etc. please don't\n> hesitate to voice them.\n> \n> Thank you very much for your time, :)\n> George\n> \n> (*) - This means that clang can catch almost as many *types* of bugs\n> as GCC at compile-time. Due to architectural constraints, clang can\n> only perform these checks prior to optimizing code.\n> So, clang is still unable to statically diagnose bugs that require it\n> to do more than simple constant folding. __builtin_object_size,\n> however, isn't required to be folded until after we optimize code, so\n> many dynamic checks can still take advantage of optimizations.\n>","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","mailing list libc-alpha@sourceware.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=sourceware.org\n\t(client-ip=209.132.180.131; helo=sourceware.org;\n\tenvelope-from=libc-alpha-return-87320-incoming=patchwork.ozlabs.org@sourceware.org;\n\treceiver=)","ozlabs.org; dkim=pass (1024-bit key;\n\tsecure) header.d=sourceware.org header.i=@sourceware.org\n\theader.b=\"WQp/UGb0\"; dkim-atps=neutral","sourceware.org; auth=none"],"Received":["from sourceware.org (server1.sourceware.org [209.132.180.131])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3ygfmc06mTz9sRV\n\tfor ;\n\tTue, 21 Nov 2017 07:03:43 +1100 (AEDT)","(qmail 88814 invoked by alias); 20 Nov 2017 20:03:37 -0000","(qmail 88803 invoked by uid 89); 20 Nov 2017 20:03:37 -0000"],"DomainKey-Signature":"a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id\n\t:list-unsubscribe:list-subscribe:list-archive:list-post\n\t:list-help:sender:subject:to:references:from:cc:message-id:date\n\t:mime-version:in-reply-to:content-type\n\t:content-transfer-encoding; q=dns; s=default; b=tM2+cVIQqor6wW5k\n\tt85s3TOgONLJaSSx5h3Pbc1w1PpzbaxfA2mI/m8f19+FFu0/jdwDZAAZrGDccR7/\n\tZHHFIFNGMCiwm/q3kxkovwhe4KjoRzh7AQq50Z2AxggZoywSnaO+VMmHisnLOoi4\n\trxsNzHBGyB67tWhISA6rSGpAKl4=","DKIM-Signature":"v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id\n\t:list-unsubscribe:list-subscribe:list-archive:list-post\n\t:list-help:sender:subject:to:references:from:cc:message-id:date\n\t:mime-version:in-reply-to:content-type\n\t:content-transfer-encoding; s=default; bh=uq5h0O7nWswnf+fYhTNVKT\n\tctpMI=; b=WQp/UGb0oF9ihSUhol6B+Sw/WZnJIylDJJFFxoJy5kvfb3xX5im/1N\n\t5/fJGQ9Fa6qwJpy7+ZPQgvHnVTRodBi4y00pGmt/qHqr/Ej572MhwraPQJrBKljx\n\tZf0lbWp8dCR2XjKiqdYyVQnWuguGIU473ZnSQVyi9w8hh2/0E3Z5Y=","Mailing-List":"contact libc-alpha-help@sourceware.org; run by ezmlm","Precedence":"bulk","List-Id":"","List-Unsubscribe":"","List-Subscribe":"","List-Archive":"","List-Post":"","List-Help":",\n\t","Sender":"libc-alpha-owner@sourceware.org","X-Virus-Found":"No","X-Spam-SWARE-Status":"No, score=-6.9 required=5.0 tests=AWL, BAYES_00,\n\tGIT_PATCH_2, KAM_ASCII_DIVIDERS, KB_WAM_FROM_NAME_SINGLEWORD,\n\tRCVD_IN_DNSWL_NONE,\n\tSPF_PASS autolearn=ham version=3.3.2 spammy=tough, fragile,\n\teveryones, 7.1","X-HELO":"mail-qk0-f182.google.com","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:subject:to:references:from:cc:message-id:date\n\t:user-agent:mime-version:in-reply-to:content-language\n\t:content-transfer-encoding;\n\tbh=8eldRvGztRyvQnJSGUMuehsx2jOMw9tvaauNR15STS4=;\n\tb=d9lHRCztlksTQp5UAs67yinM4w9lRjOuUQtse7g7rq72ZsX0Fy7aF63oYbnOhZ5Llz\n\tJg3U52Yz3x419xQLyApywxQPXOCfLx+vOSer2L5x9QI6t9T4J0/Be4QGQ4lb/eQTkmeg\n\tuqC69jvJ+deUm0qvYIgniIQHZD9VPKPZs/i5bgiVJzaEciouPbl8+2flCkR+SqQA/9Ip\n\tCbsyePYwZcCKt5B7WhVepndfpto7TU+WBkpRlmOQFHzEn5f/lqiErk9SUufKI1WsmSnQ\n\tnuUAsCUaoGNSIqApnAC2t3s2o4KmsdYxvIuxx9hAiXFKAsd+PeSPGEHMHbPuQvaoXYrE\n\tBStw==","X-Gm-Message-State":"AJaThX6/RBsrPOn6WWKGPEl9UgPCUsa24l+mVNrXfMQc50ygtPKaVxFZ\n\tNJiAh23bO+jOnjYurYextnvCSQ==","X-Google-Smtp-Source":"AGs4zMZDQx48PLijz7lTcpOP4+5bLuv+Lr4P7wqONZfJxFJctcyymFppYArBNknCrPE08VTMrCx2AA==","X-Received":"by 10.55.122.135 with SMTP id v129mr2981826qkc.104.1511208213084;\n\tMon, 20 Nov 2017 12:03:33 -0800 (PST)","Subject":"Re: [RFC][PATCH] Refactoring FORTIFY","To":"libc-alpha@sourceware.org","References":"","From":"Adhemerval Zanella ","Cc":"George Burgess IV ","Message-ID":"<41677d63-4cec-e24b-e4b7-378aa030a0f7@linaro.org>","Date":"Mon, 20 Nov 2017 18:03:28 -0200","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.4.0","MIME-Version":"1.0","In-Reply-To":"","Content-Type":"text/plain; charset=utf-8","Content-Transfer-Encoding":"8bit"}},{"id":1815782,"web_url":"http://patchwork.ozlabs.org/comment/1815782/","msgid":"","list_archive_url":null,"date":"2017-12-05T04:52:51","subject":"Re: [RFC][PATCH] Refactoring FORTIFY","submitter":{"id":72344,"url":"http://patchwork.ozlabs.org/api/people/72344/","name":"George Burgess IV","email":"george.burgess.iv@gmail.com"},"content":"Apologies for the lag; catching up from a vacation.\n\n> __use_clang_fortify is a compiler defined flag which is (?) define only\n> for clang 5.0 or higher.\n\nThe compiler feature we key off of in clang for this is\n`overloadable_unmarked`, which isn't overly interesting in itself, but\nit does indicate whether clang has the last feature we need\nin order to implement FORTIFY in the way this patch does.\n\n> In any case the document referenced is a good\n> addition for explanation, but I usually prefer to have a more self\n> explanatory detail on the thread and or email itself.\n\nWell, it's not exactly a *short* explanation, but I did include details\non how this all works at the end of this email. Please let me know\nif you had something else in mind, or if there's anything I can\nexpand on. :)\n\n> I really want to avoid a compiler specific flag to deactivate fortify\n> where there is already in place better approach [...]\n\nYeah, the goal was to be as backwards compatible as possible\n(so people could still have the FORTIFY protection they have\ntoday if they didn't want to tweak their code), but FORTIFY on\nclang today doesn't really provide a great experience, so I'm\nhappy to keep FORTIFY all-or-nothing.\n\n> Indeed to move forward on review we will need to split this patch by\n> family functions, maybe an initial patch to add the required macros\n> and gcc required refactoring and other for family of functions or\n> by headers with the adjustments for clang.\n\nSounds good. I'll start on that shortly. :)\n\n> The only issue I see is lacking of testing I do not have an easier\n> solution. One option would to try check for clang with support for\n> fortify on path and add extra rules for build the fortify tests\n> with clang as well, but I am not sure how complex would be to adjust\n> current testcase for such scenario.\n\nGood call. I'll see if I can make this work.\n\n-------\n\n# Details of implementation\n\nClang's FORTIFY implementation boils down to a set of overloads of\nstandard library functions. We have special attributes we can\noverload on (enable_if + pass_object_size) while keeping the\nsame language-level function type. In overload resolution, clang\nprefers functions that have these attributes over overloads without,\nall else being equal, which allows us to 'intercept' all calls to\nFORTIFY'ed functions.\n\n(These overloads do all have C++-like mangled names, but they're\nalso all static + always_inline'd, so the fact that we're using\noverloads shouldn't be easily visible to the user.)\n\nFor compile-time diagnostics, clang uses diagnose_if, which is a\nfunction-level attribute that tries to evaluate a condition at each\ncallsite of a function. If the condition is true, it'll emit a warning\nor error.\n\nDue to how clang's architected (no inlining before we run\noptimizations; no AST/accurate type info is available during\noptimizations), we also need to use the pass_object_size(N) attribute\non function parameters that we need to call __builtin_object_size on.\nThis adds a hidden size_t param to the parameter's function, and\ncauses all calls to said function to pass __builtin_object_size(p, N)\nas that hidden parameter.\n\nThere are also a number of cases where FORTIFY uses\npass_object_size on functions that don't call __builtin_object_size.\nThis is generally for some combination of three reasons:\n- there's nothing to overload on (e.g. see printf),\n- as noted above, in a set with two overloads that have identical\n signatures (in C/C++), the one with pass_object_size wins, and\n- functions with one or more parameters that have the\n pass_object_size attribute cannot have their address taken.\n\nWithout the last bullet, code like:\n\nvoid foo(void *fn);\nvoid bar() { foo(open); }\n\nbreaks, since we have open(const char *, int) and\nopen(const char *, int, int) overloads.\n\nPutting this all into practice, improving run-time bounds\nchecking for clang FORTIFY is simply an issue of adding\npass_object_size to functions. Compile-time checks, OTOH,\nare a bit more interesting, since GCC wants the check to live in\nthe function's body, whereas clang wants it to live in a function-level\nattribute. My patch adds\n__FORTIFY_PRECONDITIONS/__FORTIFY_FUNCTION_END\nmacros, which turn into balanced braces in GCC, and are nops in\nclang.\n\nThe macros that emit diagnostics (e.g.\n__FORTIFY_WARNING_ONLY_IF_BOS_LT2) either turn into\ndiagnose_if on clang, or unfold into a FORTIFY warning function\ndeclaration + call on GCC. The call is logically unreachable, but\ndone in a way that GCC can't DCE it if we need to emit a\ndiagnostic. Because we're hiding all of this behind a macro,\nmany textual FORTIFY function bodies turn into:\n{\n if (__FORTIFY_CALL_CHK && __bos (__ptr) != 1)\n return __foo_chk (__ptr, __bos (__ptr), ...);\n return __foo_real (__ptr, ...);\n}\n\n...Where __FORTIFY_CALL_CHK is always 1 on clang, but\non GCC, it's a variable (which should be trivially foldable to a\nconstant after a tiny bit of optimization). It contains whether\nor not our static checks were able to verify that the call must\nbe safe (0 if guaranteed safe, 1 if not). It's a bit ugly, but\nit matches how we act in the current FORTIFY implementation.\n\nTrue variadic functions are a bit of a pain point, since clang can't\ninline them and use __va_arg_pack () like GCC does. So, if\navailable, clang falls back on va_arg versions (vprintf instead of\nprintf, ...) instead.\n\nFinally, C's variadic fauxverloads (like open()) are handled by\nactual overloads. I've yet to find a clean way to stamp these out\nwith macros, so this patch just uses one function per reasonable\nsignature of a function.\n\n...And I think that's about it for the nitty-gritty of the actual\nimplementation. As you noted, going through macros makes\nboth GCC and Clang emit \"note:\"s about each macro; the\nimplementation of some of these macros tries to keep that to\na bare minimum, at the cost of some repetition.\n\nHope this helped, :)\nGeorge\n\nOn Mon, Nov 20, 2017 at 3:03 PM, Adhemerval Zanella\n wrote:\n> On 11/09/2017 03:26, George Burgess IV wrote:\n>> Hello,\n>>\n>> Attached is a patch that aims to substantially improve FORTIFY's\n>> usefulness with clang, and make defining FORTIFY'ed functions require\n>> less ceremony.\n>>\n>> I'm not looking for a thorough review at this time, nor do I hope to\n>> land this patch in one piece. The goal of this thread is to ensure\n>> that everyone's more or less happy with where I'd like to take glibc's\n>> FORTIFY implementation.\n>\n> Thanks for the patch and patience. The idea sound reasonable and it will\n> be indeed a good addition to extend fortify functionality to clang as well.\n>\n>>\n>> Please note that this change is intended to be a functional nop for\n>> all compilers that aren't clang >= 5.0, which was just released last\n>> Thursday.\n>\n> As a potential side note it would be good to add some short explanation\n> of the internal required to adjust it for clang, for instance that\n> __use_clang_fortify is a compiler defined flag which is (?) define only\n> for clang 5.0 or higher. In any case the document referenced is a good\n> addition for explanation, but I usually prefer to have a more self\n> explanatory detail on the thread and or email itself.\n>\n>>\n>> Diving in: as said, this patch removes a lot of duplication from\n>> FORTIFY in the common case, and makes FORTIFY far more useful for\n>> those who use glibc with clang. Namely, with this patch, clang becomes\n>> capable of emitting compile-time diagnostics on par (*) with GCC's,\n>> and clang's ability to perform run-time checks is substantially\n>> improved over what we have today.\n>>\n>> It essentially does this by wrapping up the majority of the\n>> compiler-specific incantations (declaring __foo_chk_warn,\n>> conditionally calling it, ...) behind a macro, and uses that to stamp\n>> out FORTIFY's compile-time diagnostic bits. While this approach is the\n>> cleanest I've been able to come up with, it has potential downsides:\n>>\n>> - Compile-time diagnostics with GCC are somewhat different than what\n>> they are today. To show this, I've attached tst-chk2-output.diff,\n>> which is a diff of the diagnostics produced by running GCC 7.1 on\n>> debug/tst-chk2.c. I don't find the difference to be substantial, but\n>> it does exist.\n>\n> Taking your provided file as an example I do not see it as blocker\n> for this approach. Although the new warning prints the macros used\n> to parametrize the builtins invocation, I think it still shows enough\n> information for debugging. For instance:\n>\n> -../libio/bits/stdio2.h:64:10: warning: ‘__builtin___snprintf_chk’: specified bound 3 exceeds the size 2 of the destination [-Wstringop-overflow=]\n> - return __builtin___snprintf_chk (__s, __n, __USE_FORTIFY_LEVEL - 1,\n> - ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n> - __bos (__s), __fmt, __va_arg_pack ());\n> - ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n> +../libio/bits/stdio2.h:79:7: warning: ‘__builtin___snprintf_chk’: specified bound 3 exceeds the size 2 of the destination [-Wstringop-overflow=]\n> + int __result = __FORTIFY_CALL_VA_BUILTIN (snprintf, __s, __n,\n>\n> Also, some seems more convoluted as:\n>\n> In function ‘wmemmove’,\n> inlined from ‘do_test’ at tst-chk1.c:681:3:\n> -../wcsmbs/bits/wchar2.h:77:9: warning: call to ‘__wmemmove_chk_warn’ declared with attribute warning: wmemmove called with length bigger than size of destination buffer\n> - return __wmemmove_chk_warn (__s1, __s2, __n,\n> - ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n> - __bos0 (__s1) / sizeof (wchar_t));\n> - ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n> +../wcsmbs/bits/wchar2.h:56:42: warning: call to ‘__wmemmove_warn’ declared with attribute warning: wmemmove called with length bigger than size of destination buffer\n> + __FORTIFY_WARNING_ONLY_IF_BOS0_LT2 (__wmemmove_warn, __n, __s1,\n> +../misc/sys/cdefs.h:234:5: note: in definition of macro ‘__FORTIFY_WARNING_ONLY_IF_BOS0_LT2’\n> + err_fn (); \\\n> + ^~~~~~\n>\n> Which might trigger an warning with different internal names being used\n> and also with a more convoluted warning which points to an internal name\n> instead direct to a builtin. I still think this is non blocker since\n> the warning is still meaningful and correct to point the api usage issue.\n>\n>> - In very rare cases, the code generated by GCC will be a bit worse\n>> (e.g. slower+larger) with this patch. I know this may be a tough sell,\n>> but please hear me out. :)\n>>\n>> With this patch, we sometimes emit diagnostics by emitting code like:\n>> if (should_emit_compile_time_warning) {\n>> volatile char c = 0;\n>> if (__glibc_unlikely (c))\n>> function_with_warnattr ();\n>> }\n>>\n>> Where `should_emit_compile_time_warning` always folds to a constant\n>> during compilation. So, 0 diagnostics should mean 0 change in code\n>> quality.\n>>\n>> I don't believe this is a deal-breaker, since:\n>> - if you're using FORTIFY, you presumably care enough to fix\n>> FORTIFY-related warnings, which makes this regression nonexistent for\n>> you,\n>> - if you're using FORTIFY, you know there will be a (small, but\n>> present) performance penalty,\n>> - directly after each __glibc_unlikely(c) branch is call to a FORTIFY\n>> function with known broken input, which should abort the program\n>> anyway, and\n>> - this doesn't apply to *all* diagnostics (e.g. bad calls to open()\n>> don't have this penalty); just ones where we can unify clang's and\n>> GCC's diagnostic emission bits.\n>\n> I also agree potential pessimization on code that triggers the fortify\n> checks is not really a blocker. The only issue I would consider for\n> it would be if hot path for fortified code also get slower/larger,\n> but it does not seem to be the case.\n>\n>>\n>> In any case, please see binary-output.diff for an idea of the\n>> difference this makes on code compiled with GCC 7.1. The function\n>> being compiled was a call to wmemmove with an undersized buffer. With\n>> a sufficiently large buffer, both today's FORTIFY implementation and\n>> the proposed one produce identical bodies for the function in\n>> question.\n>>\n>> Other than that, I know of no regressions that this patch causes with GCC.\n>>\n>> For clang, in very rare cases (read: I've seen ~10 instances of this\n>> testing similar implementations across Android, ChromeOS, and another\n>> very large code base), it can also break existing code. For specifics\n>> on that, and an overview on how clang's FORTIFY implementation works,\n>> please see\n>> https://docs.google.com/document/d/1DFfZDICTbL7RqS74wJVIJ-YnjQOj1SaoqfhbgddFYSM/edit?usp=sharing\n>\n> For 'Incompatibilities between clang and GCC FORTIFY' chapter in your\n> documentation, the first one I do not see really an issue because\n> relying on compiler constant fold strlen is quite fragile. The second\n> one seem more a minor issue, but the a compiler details for a very\n> specialized usage. I do not have a strong opinion if they should be\n> used as blockers.\n>\n>> The \"How does clang handle it?\" section covers the primary attributes\n>> this patch uses, and the \"Incompatibilities between clang and GCC\n>> FORTIFY\" section covers places where this patch might break existing\n>> clang users.\n>>\n>> Though I expect clang breakages to be very rare and trivial to fix,\n>> this patch introduces a _CLANG_FORTIFY_DISABLE macro, which can be\n>> used to turn this entire patch into a nop for clang >= 5.0.\n>\n> I really want to avoid a compiler specific flag to deactivate fortify\n> where there is already in place better approach (either adjusting\n> the code or disabling fortify). Also it means it would need to to\n> continue export such macro to maintain compatibility, which also adds\n> a lot of complexity with no so straightforward gains.\n>\n>>\n>> -----\n>>\n>> I apologize if this is a lot to dump into one email. As said, if we\n>> decide this is an acceptable direction to head in, I hope to land this\n>> patch in many easily reviewable parts later on.\n>\n> Indeed to move forward on review we will need to split this patch by\n> family functions, maybe an initial patch to add the required macros\n> and gcc required refactoring and other for family of functions or\n> by headers with the adjustments for clang.\n>\n> The only issue I see is lacking of testing I do not have an easier\n> solution. One option would to try check for clang with support for\n> fortify on path and add extra rules for build the fortify tests\n> with clang as well, but I am not sure how complex would be to adjust\n> current testcase for such scenario.\n>\n>>\n>> If you have any questions, comments, concerns, etc. please don't\n>> hesitate to voice them.\n>>\n>> Thank you very much for your time, :)\n>> George\n>>\n>> (*) - This means that clang can catch almost as many *types* of bugs\n>> as GCC at compile-time. Due to architectural constraints, clang can\n>> only perform these checks prior to optimizing code.\n>> So, clang is still unable to statically diagnose bugs that require it\n>> to do more than simple constant folding. __builtin_object_size,\n>> however, isn't required to be folded until after we optimize code, so\n>> many dynamic checks can still take advantage of optimizations.\n>>\n\nOn Mon, Nov 20, 2017 at 12:03 PM, Adhemerval Zanella\n wrote:\n> On 11/09/2017 03:26, George Burgess IV wrote:\n>> Hello,\n>>\n>> Attached is a patch that aims to substantially improve FORTIFY's\n>> usefulness with clang, and make defining FORTIFY'ed functions require\n>> less ceremony.\n>>\n>> I'm not looking for a thorough review at this time, nor do I hope to\n>> land this patch in one piece. The goal of this thread is to ensure\n>> that everyone's more or less happy with where I'd like to take glibc's\n>> FORTIFY implementation.\n>\n> Thanks for the patch and patience. The idea sound reasonable and it will\n> be indeed a good addition to extend fortify functionality to clang as well.\n>\n>>\n>> Please note that this change is intended to be a functional nop for\n>> all compilers that aren't clang >= 5.0, which was just released last\n>> Thursday.\n>\n> As a potential side note it would be good to add some short explanation\n> of the internal required to adjust it for clang, for instance that\n> __use_clang_fortify is a compiler defined flag which is (?) define only\n> for clang 5.0 or higher. In any case the document referenced is a good\n> addition for explanation, but I usually prefer to have a more self\n> explanatory detail on the thread and or email itself.\n>\n>>\n>> Diving in: as said, this patch removes a lot of duplication from\n>> FORTIFY in the common case, and makes FORTIFY far more useful for\n>> those who use glibc with clang. Namely, with this patch, clang becomes\n>> capable of emitting compile-time diagnostics on par (*) with GCC's,\n>> and clang's ability to perform run-time checks is substantially\n>> improved over what we have today.\n>>\n>> It essentially does this by wrapping up the majority of the\n>> compiler-specific incantations (declaring __foo_chk_warn,\n>> conditionally calling it, ...) behind a macro, and uses that to stamp\n>> out FORTIFY's compile-time diagnostic bits. While this approach is the\n>> cleanest I've been able to come up with, it has potential downsides:\n>>\n>> - Compile-time diagnostics with GCC are somewhat different than what\n>> they are today. To show this, I've attached tst-chk2-output.diff,\n>> which is a diff of the diagnostics produced by running GCC 7.1 on\n>> debug/tst-chk2.c. I don't find the difference to be substantial, but\n>> it does exist.\n>\n> Taking your provided file as an example I do not see it as blocker\n> for this approach. Although the new warning prints the macros used\n> to parametrize the builtins invocation, I think it still shows enough\n> information for debugging. For instance:\n>\n> -../libio/bits/stdio2.h:64:10: warning: ‘__builtin___snprintf_chk’: specified bound 3 exceeds the size 2 of the destination [-Wstringop-overflow=]\n> - return __builtin___snprintf_chk (__s, __n, __USE_FORTIFY_LEVEL - 1,\n> - ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n> - __bos (__s), __fmt, __va_arg_pack ());\n> - ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n> +../libio/bits/stdio2.h:79:7: warning: ‘__builtin___snprintf_chk’: specified bound 3 exceeds the size 2 of the destination [-Wstringop-overflow=]\n> + int __result = __FORTIFY_CALL_VA_BUILTIN (snprintf, __s, __n,\n>\n> Also, some seems more convoluted as:\n>\n> In function ‘wmemmove’,\n> inlined from ‘do_test’ at tst-chk1.c:681:3:\n> -../wcsmbs/bits/wchar2.h:77:9: warning: call to ‘__wmemmove_chk_warn’ declared with attribute warning: wmemmove called with length bigger than size of destination buffer\n> - return __wmemmove_chk_warn (__s1, __s2, __n,\n> - ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n> - __bos0 (__s1) / sizeof (wchar_t));\n> - ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n> +../wcsmbs/bits/wchar2.h:56:42: warning: call to ‘__wmemmove_warn’ declared with attribute warning: wmemmove called with length bigger than size of destination buffer\n> + __FORTIFY_WARNING_ONLY_IF_BOS0_LT2 (__wmemmove_warn, __n, __s1,\n> +../misc/sys/cdefs.h:234:5: note: in definition of macro ‘__FORTIFY_WARNING_ONLY_IF_BOS0_LT2’\n> + err_fn (); \\\n> + ^~~~~~\n>\n> Which might trigger an warning with different internal names being used\n> and also with a more convoluted warning which points to an internal name\n> instead direct to a builtin. I still think this is non blocker since\n> the warning is still meaningful and correct to point the api usage issue.\n>\n>> - In very rare cases, the code generated by GCC will be a bit worse\n>> (e.g. slower+larger) with this patch. I know this may be a tough sell,\n>> but please hear me out. :)\n>>\n>> With this patch, we sometimes emit diagnostics by emitting code like:\n>> if (should_emit_compile_time_warning) {\n>> volatile char c = 0;\n>> if (__glibc_unlikely (c))\n>> function_with_warnattr ();\n>> }\n>>\n>> Where `should_emit_compile_time_warning` always folds to a constant\n>> during compilation. So, 0 diagnostics should mean 0 change in code\n>> quality.\n>>\n>> I don't believe this is a deal-breaker, since:\n>> - if you're using FORTIFY, you presumably care enough to fix\n>> FORTIFY-related warnings, which makes this regression nonexistent for\n>> you,\n>> - if you're using FORTIFY, you know there will be a (small, but\n>> present) performance penalty,\n>> - directly after each __glibc_unlikely(c) branch is call to a FORTIFY\n>> function with known broken input, which should abort the program\n>> anyway, and\n>> - this doesn't apply to *all* diagnostics (e.g. bad calls to open()\n>> don't have this penalty); just ones where we can unify clang's and\n>> GCC's diagnostic emission bits.\n>\n> I also agree potential pessimization on code that triggers the fortify\n> checks is not really a blocker. The only issue I would consider for\n> it would be if hot path for fortified code also get slower/larger,\n> but it does not seem to be the case.\n>\n>>\n>> In any case, please see binary-output.diff for an idea of the\n>> difference this makes on code compiled with GCC 7.1. The function\n>> being compiled was a call to wmemmove with an undersized buffer. With\n>> a sufficiently large buffer, both today's FORTIFY implementation and\n>> the proposed one produce identical bodies for the function in\n>> question.\n>>\n>> Other than that, I know of no regressions that this patch causes with GCC.\n>>\n>> For clang, in very rare cases (read: I've seen ~10 instances of this\n>> testing similar implementations across Android, ChromeOS, and another\n>> very large code base), it can also break existing code. For specifics\n>> on that, and an overview on how clang's FORTIFY implementation works,\n>> please see\n>> https://docs.google.com/document/d/1DFfZDICTbL7RqS74wJVIJ-YnjQOj1SaoqfhbgddFYSM/edit?usp=sharing\n>\n> For 'Incompatibilities between clang and GCC FORTIFY' chapter in your\n> documentation, the first one I do not see really an issue because\n> relying on compiler constant fold strlen is quite fragile. The second\n> one seem more a minor issue, but the a compiler details for a very\n> specialized usage. I do not have a strong opinion if they should be\n> used as blockers.\n>\n>> The \"How does clang handle it?\" section covers the primary attributes\n>> this patch uses, and the \"Incompatibilities between clang and GCC\n>> FORTIFY\" section covers places where this patch might break existing\n>> clang users.\n>>\n>> Though I expect clang breakages to be very rare and trivial to fix,\n>> this patch introduces a _CLANG_FORTIFY_DISABLE macro, which can be\n>> used to turn this entire patch into a nop for clang >= 5.0.\n>\n> I really want to avoid a compiler specific flag to deactivate fortify\n> where there is already in place better approach (either adjusting\n> the code or disabling fortify). Also it means it would need to to\n> continue export such macro to maintain compatibility, which also adds\n> a lot of complexity with no so straightforward gains.\n>\n>>\n>> -----\n>>\n>> I apologize if this is a lot to dump into one email. As said, if we\n>> decide this is an acceptable direction to head in, I hope to land this\n>> patch in many easily reviewable parts later on.\n>\n> Indeed to move forward on review we will need to split this patch by\n> family functions, maybe an initial patch to add the required macros\n> and gcc required refactoring and other for family of functions or\n> by headers with the adjustments for clang.\n>\n> The only issue I see is lacking of testing I do not have an easier\n> solution. One option would to try check for clang with support for\n> fortify on path and add extra rules for build the fortify tests\n> with clang as well, but I am not sure how complex would be to adjust\n> current testcase for such scenario.\n>\n>>\n>> If you have any questions, comments, concerns, etc. please don't\n>> hesitate to voice them.\n>>\n>> Thank you very much for your time, :)\n>> George\n>>\n>> (*) - This means that clang can catch almost as many *types* of bugs\n>> as GCC at compile-time. Due to architectural constraints, clang can\n>> only perform these checks prior to optimizing code.\n>> So, clang is still unable to statically diagnose bugs that require it\n>> to do more than simple constant folding. __builtin_object_size,\n>> however, isn't required to be folded until after we optimize code, so\n>> many dynamic checks can still take advantage of optimizations.\n>>","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","mailing list libc-alpha@sourceware.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=sourceware.org\n\t(client-ip=209.132.180.131; helo=sourceware.org;\n\tenvelope-from=libc-alpha-return-87810-incoming=patchwork.ozlabs.org@sourceware.org;\n\treceiver=)","ozlabs.org; dkim=pass (1024-bit key;\n\tsecure) header.d=sourceware.org header.i=@sourceware.org\n\theader.b=\"b9wpmG94\"; dkim-atps=neutral","sourceware.org; auth=none"],"Received":["from sourceware.org (server1.sourceware.org [209.132.180.131])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3yrTsl42nSz9s0g\n\tfor ;\n\tTue, 5 Dec 2017 15:53:46 +1100 (AEDT)","(qmail 38238 invoked by alias); 5 Dec 2017 04:53:39 -0000","(qmail 38228 invoked by uid 89); 5 Dec 2017 04:53:38 -0000"],"DomainKey-Signature":"a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id\n\t:list-unsubscribe:list-subscribe:list-archive:list-post\n\t:list-help:sender:mime-version:in-reply-to:references:from:date\n\t:message-id:subject:to:cc:content-type\n\t:content-transfer-encoding; q=dns; s=default; b=n+v5Z1mqL2kytX+4\n\tvtVfcPzbR0U+/crnnM3acyUXvW4Q9Tb2tSZ649nljxDIm7llm58X5DwfqlaI3RXv\n\tM32CEHNb69n81vXTrPN54IIorLBNjKH0TqIVCCILwYlfdoLUYRgBs+jcBuszrQyk\n\t1W2ZdwmCgQ+Cavk5SCcjAx9kefE=","DKIM-Signature":"v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id\n\t:list-unsubscribe:list-subscribe:list-archive:list-post\n\t:list-help:sender:mime-version:in-reply-to:references:from:date\n\t:message-id:subject:to:cc:content-type\n\t:content-transfer-encoding; s=default; bh=aFROYe0/5ADDkETt8enMGu\n\tMqoJ0=; b=b9wpmG94tPB3Y+1juZVWtzfOPLog/Tq/E6sgL/7n9/XHUJjiG7JO6V\n\tzNXBEX6xcLDfgWFsY70ZqjeWbKSpH9/5pqWqVevcBclQ6EUgJK+YCUEXLt1nUd96\n\tK9mPd+mC1B52LAV0uRVZGnUFQ0zvI32nqPp7YBKFKLdEo8Hw6l8eg=","Mailing-List":"contact libc-alpha-help@sourceware.org; run by ezmlm","Precedence":"bulk","List-Id":"","List-Unsubscribe":"","List-Subscribe":"","List-Archive":"","List-Post":"","List-Help":",\n\t","Sender":"libc-alpha-owner@sourceware.org","X-Virus-Found":"No","X-Spam-SWARE-Status":"No, score=-6.6 required=5.0 tests=AWL, BAYES_00,\n\tFREEMAIL_FROM, GIT_PATCH_2, KAM_ASCII_DIVIDERS,\n\tRCVD_IN_DNSWL_NONE,\n\tSPF_PASS autolearn=ham version=3.3.2 spammy=George, sk:binary,\n\tTaking, everyones","X-HELO":"mail-pf0-f169.google.com","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:mime-version:in-reply-to:references:from:date\n\t:message-id:subject:to:cc:content-transfer-encoding;\n\tbh=VZpUZJZ1lVAUyHX+e5Yi3s+DRt0ho6j2SrcvUEbFKBc=;\n\tb=JMIxIlPsPDWd5Z0vzjMCYsey3VxLBZYitL1/+VYIjG/vgV/v0SdEhN1Dc+nWRl84XS\n\tZm0im+u01Gne5WHHrzQUguECwC6HUehpdZ1MTRadSm1R2KDKQ1o4D1idC/03+wybxQJP\n\tqbHe0Xs00j6V0pfMWT5NGHbbCs1/pMddmd5hCAfVfvpRdjAdR7LCgu6H3E2qlyB7rKNH\n\tOZbpEZ/6azwk2a7RVKtmwPItjNWoXciAffN0cZkBBd0Cu+/0FH6vh0kinH3PVnen8SgF\n\t4n9cWWCPkm5EoQRs8vlY1P6RGXvWGi2P9wf61cmcebfGXrRJV8uZOvwEDcT8lfLYpjXz\n\tcBFg==","X-Gm-Message-State":"AJaThX6thJcx2o6YNO1hml9rOuv8+pnAhwvOixGRxM10ZafEK9ijkJv3\n\tSwMewEsHEDLI02GCgJAzqlZbmJjKn6NwhToNRhI=","X-Google-Smtp-Source":"AGs4zMYONYWLd6s390hTmPidChU+5m6CRnjKemyr2MEw4N4azZgPm/lf/LpqPWzsRh3jLrTB6ZGomWqJQ+V7z98QJFQ=","X-Received":"by 10.159.207.134 with SMTP id z6mr17191060plo.164.1512449612028;\n\tMon, 04 Dec 2017 20:53:32 -0800 (PST)","MIME-Version":"1.0","In-Reply-To":"<41677d63-4cec-e24b-e4b7-378aa030a0f7@linaro.org>","References":"\n\t<41677d63-4cec-e24b-e4b7-378aa030a0f7@linaro.org>","From":"George Burgess IV ","Date":"Mon, 4 Dec 2017 20:52:51 -0800","Message-ID":"","Subject":"Re: [RFC][PATCH] Refactoring FORTIFY","To":"Adhemerval Zanella ","Cc":"libc-alpha@sourceware.org","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"quoted-printable"}}]