From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751920AbdC0TjP (ORCPT ); Mon, 27 Mar 2017 15:39:15 -0400 Received: from mail-wr0-f176.google.com ([209.85.128.176]:35872 "EHLO mail-wr0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751327AbdC0TjI (ORCPT ); Mon, 27 Mar 2017 15:39:08 -0400 From: Rasmus Villemoes To: Kees Cook Cc: Andrew Donnellan , LKML , Emese Revfy , Arnd Bergmann , Josh Triplett , PaX Team , Masahiro Yamada , minipli@ld-linux.so, Russell King , Catalin Marinas , David Brown , "benh\@kernel.crashing.org" , Thomas Gleixner , Andrew Morton , Jeff Layton , Sam Ravnborg , "kernel-hardening\@lists.openwall.com" Subject: Re: [PATCH v5 1/4] gcc-plugins: Add the initify gcc plugin Organization: D03 References: <1485894263-91051-1-git-send-email-keescook@chromium.org> <1485894263-91051-2-git-send-email-keescook@chromium.org> <851a0c99-db08-c3a8-f5c6-2e567971e2eb@au1.ibm.com> X-Hashcash: 1:20:170327:yamada.masahiro@socionext.com::A/j6rofAVcHYIf4j:000000000000000000000000000000000rzE X-Hashcash: 1:20:170327:david.brown@linaro.org::6in6FV9ZwrY4Nvog:0000000000000000000000000000000000000001mEX X-Hashcash: 1:20:170327:jlayton@poochiereds.net::IZbtL2WGtbCY2+vB:0000000000000000000000000000000000000020QG X-Hashcash: 1:20:170327:re.emese@gmail.com::OMt1aPjQhU48XGBk:00000000000000000000000000000000000000000002Dn2 X-Hashcash: 1:20:170327:tglx@linutronix.de::jHz/BHCk3rK7rwM7:00000000000000000000000000000000000000000002BiD X-Hashcash: 1:20:170327:sam@ravnborg.org::CJ6VSOySXr2EI2bI:02EUG X-Hashcash: 1:20:170327:catalin.marinas@arm.com::6mXjbXueth1amSdY:000000000000000000000000000000000000002du9 X-Hashcash: 1:20:170327:minipli@ld-linux.so::pau6H9UXSQlbDOuU:0000000000000000000000000000000000000000002juo X-Hashcash: 1:20:170327:kernel-hardening@lists.openwall.com::rqtjl+P7IlT7GT8y:000000000000000000000000002iOz X-Hashcash: 1:20:170327:pageexec@freemail.hu::f8VYY8qv6UBoO1d3:000000000000000000000000000000000000000002mpW X-Hashcash: 1:20:170327:linux@armlinux.org.uk::WYFWA9oUhwUxo6t7:00000000000000000000000000000000000000003klm X-Hashcash: 1:20:170327:akpm@linux-foundation.org::/yWjWKEbIvxlSEi/:0000000000000000000000000000000000004MdG X-Hashcash: 1:20:170327:keescook@chromium.org::WFkhckS/XwPCuQso:00000000000000000000000000000000000000005dD0 X-Hashcash: 1:20:170327:andrew.donnellan@au1.ibm.com::28wdvOoVI4ghuxMJ:0000000000000000000000000000000006KqA X-Hashcash: 1:20:170327:josh@joshtriplett.org::RRgZSPiUMhMCqNDl:00000000000000000000000000000000000000007HmH X-Hashcash: 1:20:170327:linux-kernel@vger.kernel.org::AedIDuR0oljgpp3P:0000000000000000000000000000000009CBW X-Hashcash: 1:20:170327:arnd@arndb.de::j3KnuHQjL9kehCnJ:0000D0Rh X-Hashcash: 1:20:170327:benh@kernel.crashing.org::4MOsR9ERCSHqYzA2:0000000000000000000000000000000000000HRa8 Date: Mon, 27 Mar 2017 21:31:02 +0200 In-Reply-To: (Kees Cook's message of "Mon, 27 Mar 2017 09:14:36 -0700") Message-ID: <87inmujz49.fsf@rasmusvillemoes.dk> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 27 2017, Kees Cook wrote: > On Mon, Mar 27, 2017 at 12:38 AM, Andrew Donnellan > wrote: >> On 01/02/17 07:24, Kees Cook wrote: >>> >>> From: Emese Revfy >>> >>> The kernel already has a mechanism to free up code and data memory that >>> is only used during kernel or module initialization. This plugin will >>> teach the compiler to find more such code and data that can be freed >>> after initialization. >> >> >> Currently checking whether we can wire this up for powerpc without too many >> problems... > > Cool, thanks. FWIW, note that this plugin is a bit back-burnered at > the moment. I've got this in my -next tree still, but it needs some > rather large changes to how it does its annotations before Linus will > accept it. Why not just hardcode the annotations in the plugin itself? I'd expect just making it know about mem*, str*, and the various *printf/printk functions would get 90% of the benefits. The prototypes of these aren't gonna change anytime soon, so there's no compelling reason to keep the annotations with the declarations. The plugin can still do its sanity checking when it compiles a function with one of these names. Rasmus From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rasmus Villemoes References: <1485894263-91051-1-git-send-email-keescook@chromium.org> <1485894263-91051-2-git-send-email-keescook@chromium.org> <851a0c99-db08-c3a8-f5c6-2e567971e2eb@au1.ibm.com> Date: Mon, 27 Mar 2017 21:31:02 +0200 In-Reply-To: (Kees Cook's message of "Mon, 27 Mar 2017 09:14:36 -0700") Message-ID: <87inmujz49.fsf@rasmusvillemoes.dk> MIME-Version: 1.0 Content-Type: text/plain Subject: [kernel-hardening] Re: [PATCH v5 1/4] gcc-plugins: Add the initify gcc plugin To: Kees Cook Cc: Andrew Donnellan , LKML , Emese Revfy , Arnd Bergmann , Josh Triplett , PaX Team , Masahiro Yamada , minipli@ld-linux.so, Russell King , Catalin Marinas , David Brown , "benh@kernel.crashing.org" , Thomas Gleixner , Andrew Morton , Jeff Layton , Sam Ravnborg , "kernel-hardening@lists.openwall.com" List-ID: On Mon, Mar 27 2017, Kees Cook wrote: > On Mon, Mar 27, 2017 at 12:38 AM, Andrew Donnellan > wrote: >> On 01/02/17 07:24, Kees Cook wrote: >>> >>> From: Emese Revfy >>> >>> The kernel already has a mechanism to free up code and data memory that >>> is only used during kernel or module initialization. This plugin will >>> teach the compiler to find more such code and data that can be freed >>> after initialization. >> >> >> Currently checking whether we can wire this up for powerpc without too many >> problems... > > Cool, thanks. FWIW, note that this plugin is a bit back-burnered at > the moment. I've got this in my -next tree still, but it needs some > rather large changes to how it does its annotations before Linus will > accept it. Why not just hardcode the annotations in the plugin itself? I'd expect just making it know about mem*, str*, and the various *printf/printk functions would get 90% of the benefits. The prototypes of these aren't gonna change anytime soon, so there's no compelling reason to keep the annotations with the declarations. The plugin can still do its sanity checking when it compiles a function with one of these names. Rasmus