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

Groups > linux.kernel > #1610384 > unrolled thread

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

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 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

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

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] | [next] | [standalone]

#1611284

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

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] | [standalone]

Back to top | Article view | linux.kernel

csiph-web