Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1609609 > unrolled thread

Re: [kernel-hardening] [PATCH v5 1/4] gcc-plugins: Add the initify gcc plugin

Started byAndrew Donnellan <andrew.donnellan@au1.ibm.com>
First post2017-03-27 11:40 +0200
Last post2017-03-28 21:10 +0200
Articles 9 — 4 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [kernel-hardening] [PATCH v5 1/4] gcc-plugins: Add the initify  gcc plugin Andrew Donnellan <andrew.donnellan@au1.ibm.com> - 2017-03-27 11:40 +0200
    Re: [kernel-hardening] [PATCH v5 1/4] gcc-plugins: Add the initify  gcc plugin Kees Cook <keescook@chromium.org> - 2017-03-27 18:20 +0200
      Re: [PATCH v5 1/4] gcc-plugins: Add the initify gcc plugin Kees Cook <keescook@chromium.org> - 2017-03-27 21:40 +0200
      Re: [PATCH v5 1/4] gcc-plugins: Add the initify gcc plugin Rasmus Villemoes <linux@rasmusvillemoes.dk> - 2017-03-27 21:40 +0200
      Re: [kernel-hardening] [PATCH v5 1/4] gcc-plugins: Add the initify  gcc plugin Arnd Bergmann <arnd@arndb.de> - 2017-03-28 10:00 +0200
        Re: [kernel-hardening] [PATCH v5 1/4] gcc-plugins: Add the initify  gcc plugin Kees Cook <keescook@chromium.org> - 2017-03-28 21:10 +0200
          Re: [kernel-hardening] [PATCH v5 1/4] gcc-plugins: Add the initify  gcc plugin Arnd Bergmann <arnd@arndb.de> - 2017-03-28 22:40 +0200
    Re: [kernel-hardening] [PATCH v5 1/4] gcc-plugins: Add the initify  gcc plugin Andrew Donnellan <andrew.donnellan@au1.ibm.com> - 2017-03-28 05:10 +0200
      Re: [kernel-hardening] [PATCH v5 1/4] gcc-plugins: Add the initify  gcc plugin Kees Cook <keescook@chromium.org> - 2017-03-28 21:10 +0200

#1609609 — Re: [kernel-hardening] [PATCH v5 1/4] gcc-plugins: Add the initify gcc plugin

FromAndrew Donnellan <andrew.donnellan@au1.ibm.com>
Date2017-03-27 11:40 +0200
SubjectRe: [kernel-hardening] [PATCH v5 1/4] gcc-plugins: Add the initify gcc plugin
Message-ID<tpzi1-5Ua-7@gated-at.bofh.it>
On 01/02/17 07:24, Kees Cook wrote:
> From: Emese Revfy <re.emese@gmail.com>
>
> 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...

> diff --git a/arch/x86/lib/Makefile b/arch/x86/lib/Makefile
> index 34a74131a12c..b98b8fdb7aaf 100644
> --- a/arch/x86/lib/Makefile
> +++ b/arch/x86/lib/Makefile
> @@ -29,6 +29,10 @@ lib-$(CONFIG_RANDOMIZE_BASE) += kaslr.o
>  obj-y += msr.o msr-reg.o msr-reg-export.o hweight.o
>
>  ifeq ($(CONFIG_X86_32),y)
> +        CFLAGS_strstr_32.o += $(INITIFY_DISABLE_VERIFIY_NOCAPTURE_FUNCTIONS)
> +        CFLAGS_string_32.o += $(INITIFY_DISABLE_VERIFIY_NOCAPTURE_FUNCTIONS)
> +        CFLAGS_memcpy_32.o += $(INITIFY_DISABLE_VERIFIY_NOCAPTURE_FUNCTIONS)

s/VERIFIY/VERIFY/g here + Makefile.gcc-plugins?


-- 
Andrew Donnellan              OzLabs, ADL Canberra
andrew.donnellan@au1.ibm.com  IBM Australia Limited

[toc] | [next] | [standalone]

#1609968

FromKees Cook <keescook@chromium.org>
Date2017-03-27 18:20 +0200
Message-ID<tpFx8-2mb-21@gated-at.bofh.it>
In reply to#1609609
On Mon, Mar 27, 2017 at 12:38 AM, Andrew Donnellan
<andrew.donnellan@au1.ibm.com> wrote:
> On 01/02/17 07:24, Kees Cook wrote:
>>
>> From: Emese Revfy <re.emese@gmail.com>
>>
>> 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.

>> diff --git a/arch/x86/lib/Makefile b/arch/x86/lib/Makefile
>> index 34a74131a12c..b98b8fdb7aaf 100644
>> --- a/arch/x86/lib/Makefile
>> +++ b/arch/x86/lib/Makefile
>> @@ -29,6 +29,10 @@ lib-$(CONFIG_RANDOMIZE_BASE) += kaslr.o
>>  obj-y += msr.o msr-reg.o msr-reg-export.o hweight.o
>>
>>  ifeq ($(CONFIG_X86_32),y)
>> +        CFLAGS_strstr_32.o +=
>> $(INITIFY_DISABLE_VERIFIY_NOCAPTURE_FUNCTIONS)
>> +        CFLAGS_string_32.o +=
>> $(INITIFY_DISABLE_VERIFIY_NOCAPTURE_FUNCTIONS)
>> +        CFLAGS_memcpy_32.o +=
>> $(INITIFY_DISABLE_VERIFIY_NOCAPTURE_FUNCTIONS)
>
>
> s/VERIFIY/VERIFY/g here + Makefile.gcc-plugins?

Ah, thanks for catching that! I'll get that fixed.

-Kees

-- 
Kees Cook
Pixel Security

[toc] | [prev] | [next] | [standalone]

#1610087 — Re: [PATCH v5 1/4] gcc-plugins: Add the initify gcc plugin

FromKees Cook <keescook@chromium.org>
Date2017-03-27 21:40 +0200
SubjectRe: [PATCH v5 1/4] gcc-plugins: Add the initify gcc plugin
Message-ID<tpIEG-4B0-15@gated-at.bofh.it>
In reply to#1609968
On Mon, Mar 27, 2017 at 12:31 PM, Rasmus Villemoes
<linux@rasmusvillemoes.dk> wrote:
> On Mon, Mar 27 2017, Kees Cook <keescook@chromium.org> wrote:
>
>> On Mon, Mar 27, 2017 at 12:38 AM, Andrew Donnellan
>> <andrew.donnellan@au1.ibm.com> wrote:
>>> On 01/02/17 07:24, Kees Cook wrote:
>>>>
>>>> From: Emese Revfy <re.emese@gmail.com>
>>>>
>>>> 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.

Yup, I think that's another entirely workable solution too. I just
meant to say that I don't have time at the moment to look at it (if
you want to, please do), and I think Emese is already happy with how
the annotations work, so I don't think she'd want to work on it either
(but she can correct me if I'm wrong).

-Kees

-- 
Kees Cook
Pixel Security

[toc] | [prev] | [next] | [standalone]

#1610089 — Re: [PATCH v5 1/4] gcc-plugins: Add the initify gcc plugin

FromRasmus Villemoes <linux@rasmusvillemoes.dk>
Date2017-03-27 21:40 +0200
SubjectRe: [PATCH v5 1/4] gcc-plugins: Add the initify gcc plugin
Message-ID<tpIEG-4B0-17@gated-at.bofh.it>
In reply to#1609968
On Mon, Mar 27 2017, Kees Cook <keescook@chromium.org> wrote:

> On Mon, Mar 27, 2017 at 12:38 AM, Andrew Donnellan
> <andrew.donnellan@au1.ibm.com> wrote:
>> On 01/02/17 07:24, Kees Cook wrote:
>>>
>>> From: Emese Revfy <re.emese@gmail.com>
>>>
>>> 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

[toc] | [prev] | [next] | [standalone]

#1610384

FromArnd Bergmann <arnd@arndb.de>
Date2017-03-28 10:00 +0200
Message-ID<tpUcN-4ow-3@gated-at.bofh.it>
In reply to#1609968
On Mon, Mar 27, 2017 at 6:14 PM, Kees Cook <keescook@chromium.org> wrote:
> On Mon, Mar 27, 2017 at 12:38 AM, Andrew Donnellan
> <andrew.donnellan@au1.ibm.com> wrote:
>> On 01/02/17 07:24, Kees Cook wrote:
>>>
>>> From: Emese Revfy <re.emese@gmail.com>
>>>
>>> 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.

I've tried turning it on again a few days ago and still got too many build
problems with my randconfig tree, so I've turned it off again. I think I've
already reported most of what I found now, so I did not send out new
reports.

      Arnd

[toc] | [prev] | [next] | [standalone]

#1611284

FromKees Cook <keescook@chromium.org>
Date2017-03-28 21:10 +0200
Message-ID<tq4Fc-3He-3@gated-at.bofh.it>
In reply to#1610384
On Tue, Mar 28, 2017 at 12:49 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Mon, Mar 27, 2017 at 6:14 PM, Kees Cook <keescook@chromium.org> wrote:
>> On Mon, Mar 27, 2017 at 12:38 AM, Andrew Donnellan
>> <andrew.donnellan@au1.ibm.com> wrote:
>>> On 01/02/17 07:24, Kees Cook wrote:
>>>>
>>>> From: Emese Revfy <re.emese@gmail.com>
>>>>
>>>> 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.
>
> I've tried turning it on again a few days ago and still got too many build
> problems with my randconfig tree, so I've turned it off again. I think I've
> already reported most of what I found now, so I did not send out new
> reports.

Hrm, with what's in -next? That's too bad. I thought everything you
reported had been fixed. Dang. :(

-Kees

-- 
Kees Cook
Pixel Security

[toc] | [prev] | [next] | [standalone]

#1611343

FromArnd Bergmann <arnd@arndb.de>
Date2017-03-28 22:40 +0200
Message-ID<tq64h-4CD-1@gated-at.bofh.it>
In reply to#1611284
On Tue, Mar 28, 2017 at 9:03 PM, Kees Cook <keescook@chromium.org> wrote:
> On Tue, Mar 28, 2017 at 12:49 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>> On Mon, Mar 27, 2017 at 6:14 PM, Kees Cook <keescook@chromium.org> wrote:
>>> On Mon, Mar 27, 2017 at 12:38 AM, Andrew Donnellan
>>> <andrew.donnellan@au1.ibm.com> wrote:
>>>> On 01/02/17 07:24, Kees Cook wrote:
>>>>>
>>>>> From: Emese Revfy <re.emese@gmail.com>
>>>>>
>>>>> 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.
>>
>> I've tried turning it on again a few days ago and still got too many build
>> problems with my randconfig tree, so I've turned it off again. I think I've
>> already reported most of what I found now, so I did not send out new
>> reports.
>
> Hrm, with what's in -next? That's too bad. I thought everything you
> reported had been fixed. Dang. :(

Here are the ones I'm still getting with around 50 randconfig builds:

0xA1433C1D Tue Mar 28 21:43:01 CEST 2017 failed
/git/arm-soc/drivers/acpi/acpica/utdebug.c: In function 'acpi_debug_print':
/git/arm-soc/drivers/acpi/acpica/utdebug.c:158:1: error:
'acpi_debug_print' captures its 3 ('function_name') parameter, please
remove it from the nocapture attribute. [-Werror]

0x46D10F38 Tue Mar 28 21:48:11 CEST 2017 failed
/git/arm-soc/lib/string.c: In function 'check_bytes8':
/git/arm-soc/lib/string.c:900:7: error: 'check_bytes8' captures its 1
('start') parameter, please remove it from the nocapture attribute.
[-Werror]
 void *check_bytes8(const u8 *start, u8 value, unsigned int bytes)
       ^~~~~~~~~~~~
0xDC65C29E Tue Mar 28 22:20:43 CEST 2017 success
0xCF5F679E Tue Mar 28 22:21:02 CEST 2017 failed
/git/arm-soc/lib/string.c: In function 'strnstr':
/git/arm-soc/lib/string.c:858:7: error: 'strnstr' captures its 1
('s1') parameter, please remove it from the nocapture attribute.
[-Werror]

I also got this a few days ago:

*** WARNING *** there are active plugins, do not report this as a bug
unless you can reproduce it without enabling any plugins.
Event                            | Plugins
PLUGIN_ATTRIBUTES                | initify_plugin
PLUGIN_START_UNIT                | initify_plugin
/git/arm-soc/arch/arm/mach-mv78xx0/common.c: In function 'mv78xx0_init':
/git/arm-soc/arch/arm/mach-mv78xx0/common.c:384:13: internal compiler
error: in search_constant_strings, at
git/arm-soc/scripts/gcc-plugins/initify_plugin.c:1375
 void __init mv78xx0_init(void)
             ^~~~~~~~~~~~
0x2b0538381b9d search_constant_strings
/git/arm-soc/scripts/gcc-plugins/initify_plugin.c:1375
0x2b0538381950 search_constant_strings
/git/arm-soc/scripts/gcc-plugins/initify_plugin.c:1335
0x2b0538381950 search_constant_strings
/git/arm-soc/scripts/gcc-plugins/initify_plugin.c:1367
0x2b0538382abe search_constant_strings
/git/arm-soc/scripts/gcc-plugins/initify_plugin.c:1506
0x2b0538382abe search_var_param
/git/arm-soc/scripts/gcc-plugins/initify_plugin.c:1419
0x2b0538382abe search_const_strs
/git/arm-soc/scripts/gcc-plugins/initify_plugin.c:1471
0x2b0538382abe initify_function_transform
/git/arm-soc/scripts/gcc-plugins/initify_plugin.c:1519
0xc679a3 execute_one_ipa_transform_pass
/home/arnd/git/gcc/gcc/passes.c:2207
0xc67b2d execute_all_ipa_transforms()
/home/arnd/git/gcc/gcc/passes.c:2249
0x8d5a46 cgraph_node::expand()
/home/arnd/git/gcc/gcc/cgraphunit.c:2029
0x8d5f1c expand_all_functions
/home/arnd/git/gcc/gcc/cgraphunit.c:2172
0x8d69ec symbol_table::compile()
/home/arnd/git/gcc/gcc/cgraphunit.c:2529
0x8d6c2c symbol_table::finalize_compilation_unit()
/home/arnd/git/gcc/gcc/cgraphunit.c:2619
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
/git/arm-soc/scripts/Makefile.build:308: recipe for target
'arch/arm/mach-mv78xx0/common.o' failed


     Arnd

[toc] | [prev] | [next] | [standalone]

#1610272

FromAndrew Donnellan <andrew.donnellan@au1.ibm.com>
Date2017-03-28 05:10 +0200
Message-ID<tpPGa-1lb-5@gated-at.bofh.it>
In reply to#1609609
On 27/03/17 18:38, Andrew Donnellan wrote:
> On 01/02/17 07:24, Kees Cook wrote:
>> From: Emese Revfy <re.emese@gmail.com>
>>
>> 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...

Added "select HAVE_GCC_PLUGIN_INITIFY_INIT_EXIT if GCC_PLUGINS" to 
arch/powerpc/Kconfig and have successfully compiled and booted a modular 
and non-modular powernv_defconfig, it looks like we handle the .exit 
sections correctly.

Could this be folded in for further testing when you get around to v6, Kees?

-- 
Andrew Donnellan              OzLabs, ADL Canberra
andrew.donnellan@au1.ibm.com  IBM Australia Limited

[toc] | [prev] | [next] | [standalone]

#1611288

FromKees Cook <keescook@chromium.org>
Date2017-03-28 21:10 +0200
Message-ID<tq4Fc-3He-19@gated-at.bofh.it>
In reply to#1610272
On Mon, Mar 27, 2017 at 8:03 PM, Andrew Donnellan
<andrew.donnellan@au1.ibm.com> wrote:
> On 27/03/17 18:38, Andrew Donnellan wrote:
>>
>> On 01/02/17 07:24, Kees Cook wrote:
>>>
>>> From: Emese Revfy <re.emese@gmail.com>
>>>
>>> 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...
>
>
> Added "select HAVE_GCC_PLUGIN_INITIFY_INIT_EXIT if GCC_PLUGINS" to
> arch/powerpc/Kconfig and have successfully compiled and booted a modular and
> non-modular powernv_defconfig, it looks like we handle the .exit sections
> correctly.
>
> Could this be folded in for further testing when you get around to v6, Kees?

Awesome, thanks for testing! I'll get it queued for a v6...

-Kees

-- 
Kees Cook
Pixel Security

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web