Re: [kernel-hardening] [PATCH v1 0/2] Introduce the initify gcc plugin
On Wed, 29 Jun 2016 18:52:27 +0100 Mark Rutland wrote: > On Wed, Jun 29, 2016 at 09:21:37AM +0100, Mark Rutland wrote: > > On Tue, Jun 28, 2016 at 01:46:04PM -0700, Kees Cook wrote: > > > On Tue, Jun 28, 2016 at 9:14 AM, Emese Revfy wrote: > > > > On Tue, 28 Jun 2016 13:57:49 +0100 > > > > Mark Rutland wrote: > > > > > > > >> On Tue, Jun 28, 2016 at 01:34:07PM +0200, Emese Revfy wrote: > > > >> > This patch set is based on the "Add support for complex gcc plugins > > > >> > that > > > >> > don't fit in a single file" patch set (git/kees/linux.git#kspp HEAD: > > > >> > e5d4798b284cd192c8b). > > > >> > > > >> I was hoping to give this a spin on arm/arm64, but I couldn't find the > > > >> prerequisite branch/tag/commit in that tree: > > > >> > > > >> https://git.kernel.org/cgit/linux/kernel/git/kees/linux.git/commit/?id=e5d4798b284cd192c8b > > > >> > > > >> Where should I be looking? > > > > > > > > Sorry, this commit was disappear. You can apply these patches to this > > > > tree: > > > > https://github.com/ephox-gcc-plugins/gcc-plugins_linux-next.git > > > > (initify branch) > > g++: fatal error: no input files > compilation terminated. > make[1]: *** [scripts/gcc-plugins/initify_plugin.so] Error 4 > make: *** [gcc-plugins] Error 2 Hi, There are some missing patches from Kees tree that's why I suggested my tree above. -- Emese
Re: [kernel-hardening] [PATCH v1 0/2] Introduce the initify gcc plugin
On Wed, Jun 29, 2016 at 09:21:37AM +0100, Mark Rutland wrote: > On Tue, Jun 28, 2016 at 01:46:04PM -0700, Kees Cook wrote: > > On Tue, Jun 28, 2016 at 9:14 AM, Emese Revfy wrote: > > > On Tue, 28 Jun 2016 13:57:49 +0100 > > > Mark Rutland wrote: > > > > > >> On Tue, Jun 28, 2016 at 01:34:07PM +0200, Emese Revfy wrote: > > >> > This patch set is based on the "Add support for complex gcc plugins > > >> > that > > >> > don't fit in a single file" patch set (git/kees/linux.git#kspp HEAD: > > >> > e5d4798b284cd192c8b). > > >> > > >> I was hoping to give this a spin on arm/arm64, but I couldn't find the > > >> prerequisite branch/tag/commit in that tree: > > >> > > >> https://git.kernel.org/cgit/linux/kernel/git/kees/linux.git/commit/?id=e5d4798b284cd192c8b > > >> > > >> Where should I be looking? > > > > > > Sorry, this commit was disappear. You can apply these patches to this > > > tree: > > > https://github.com/ephox-gcc-plugins/gcc-plugins_linux-next.git (initify > > > branch) > > > > The linux-next tree should have what you need for the plugin support. > > This is merging from my KSPP tree: > > > > https://git.kernel.org/linux/kernel/git/kees/linux.git for-next/kspp > > I didn't see the complex gcc plugins patch in that branch or linux-next, > so I take it you mean a a base for applying the complex plugin patch and > initify patches. > > I'll try to give that a go shortly. I tried to give this a go atop of kees's for-next/kspp branch, but this doesn't seem to build. With the Linaro 15.08 AArch64 toolchain, I see: [mark@leverpostej:~/src/linux]% uselinaro 15.08 make V=1 ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- set -e; : ' CHK include/config/kernel.release'; mkdir -p include/config/; echo "4.7.0-rc1$(/bin/bash ./scripts/setlocalversion .)" < include/config/auto.conf > include/config/kernel.release.tmp; if [ -r include/config/kernel.release ] && cmp -s include/config/kernel.release include/config/kernel.release.tmp; then rm -f include/config/kernel.release.tmp; else : ' UPD include/config/kernel.release'; mv -f include/config/kernel.release.tmp include/config/kernel.release; fi make -f ./scripts/Makefile.asm-generic \ src=asm obj=arch/arm64/include/generated/asm make -f ./scripts/Makefile.asm-generic \ src=uapi/asm obj=arch/arm64/include/generated/uapi/asm set -e; : ' CHK include/generated/uapi/linux/version.h'; mkdir -p include/generated/uapi/linux/; (echo \#define LINUX_VERSION_CODE 263936; echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))';) < Makefile > include/generated/uapi/linux/version.h.tmp; if [ -r include/generated/uapi/linux/version.h ] && cmp -s include/generated/uapi/linux/version.h include/generated/uapi/linux/version.h.tmp; then rm -f include/generated/uapi/linux/version.h.tmp; else : ' UPD include/generated/uapi/linux/version.h'; mv -f include/generated/uapi/linux/version.h.tmp include/generated/uapi/linux/version.h; fi rm -f include/linux/version.h set -e; : ' CHK include/generated/utsrelease.h'; mkdir -p include/generated/; if [ `echo -n "4.7.0-rc1+" | wc -c ` -gt 64 ]; then echo '"4.7.0-rc1+" exceeds 64 characters' >&2; exit 1; fi; (echo \#define UTS_RELEASE \"4.7.0-rc1+\";) < include/config/kernel.release > include/generated/utsrelease.h.tmp; if [ -r include/generated/utsrelease.h ] && cmp -s include/generated/utsrelease.h include/generated/utsrelease.h.tmp; then rm -f include/generated/utsrelease.h.tmp; else : ' UPD include/generated/utsrelease.h'; mv -f include/generated/utsrelease.h.tmp include/generated/utsrelease.h; fi mkdir -p .tmp_versions ; rm -f .tmp_versions/* test -e include/generated/autoksyms.h || \ touch include/generated/autoksyms.h make -f ./scripts/Makefile.build obj=scripts/basic (cat /dev/null; ) > scripts/basic/modules.order rm -f .tmp_quiet_recordmcount make -f ./scripts/Makefile.build obj=scripts/gcc-plugins (cat /dev/null; ) > scripts/gcc-plugins/modules.order g++ -shared -o scripts/gcc-plugins/initify_plugin.so g++: fatal error: no input files compilation terminated. make[1]: *** [scripts/gcc-plugins/initify_plugin.so] Error 4 make: *** [gcc-plugins] Error 2 Any ideas? Thanks, Mark.
Re: [kernel-hardening] [PATCH v1 0/2] Introduce the initify gcc plugin
On Tue, Jun 28, 2016 at 01:46:04PM -0700, Kees Cook wrote: > On Tue, Jun 28, 2016 at 9:14 AM, Emese Revfy wrote: > > On Tue, 28 Jun 2016 13:57:49 +0100 > > Mark Rutland wrote: > > > >> On Tue, Jun 28, 2016 at 01:34:07PM +0200, Emese Revfy wrote: > >> > This patch set is based on the "Add support for complex gcc plugins that > >> > don't fit in a single file" patch set (git/kees/linux.git#kspp HEAD: > >> > e5d4798b284cd192c8b). > >> > >> I was hoping to give this a spin on arm/arm64, but I couldn't find the > >> prerequisite branch/tag/commit in that tree: > >> > >> https://git.kernel.org/cgit/linux/kernel/git/kees/linux.git/commit/?id=e5d4798b284cd192c8b > >> > >> Where should I be looking? > > > > Sorry, this commit was disappear. You can apply these patches to this tree: > > https://github.com/ephox-gcc-plugins/gcc-plugins_linux-next.git (initify > > branch) > > The linux-next tree should have what you need for the plugin support. > This is merging from my KSPP tree: > > https://git.kernel.org/linux/kernel/git/kees/linux.git for-next/kspp I didn't see the complex gcc plugins patch in that branch or linux-next, so I take it you mean a a base for applying the complex plugin patch and initify patches. I'll try to give that a go shortly. Thanks, Mark.
Re: [kernel-hardening] Re: [PATCH v1 0/2] Introduce the initify gcc plugin
On Tue, 2016-06-28 at 18:07 -0400, valdis.kletni...@vt.edu wrote:
> On Tue, 28 Jun 2016 14:49:15 -0700, Joe Perches said:
>
> >
> > Another potentially useful plugin, especially for embedded systems,
> > would be to compress any string literal marked with
> >
> > __attribute__((format(printf, string-index,)))
> >
> > and decompress the compressed format on the stack in lib/vsprintf.c
> > vsnprintf just before use.
> Are there enough such strings in the kernel to make it worth the effort?
> I'm assuming that the string literals in printk("some string here") are
> automatically so marked?
Yes, that's the concept.
> Is there a minimum length under which the compression overhead actually
> makes it larger?
No, compression would have to be possible, otherwise it'd
be stored directly. Compression would use a special
"compressed string" header with a 2 byte overhead and
then stored with no trailing \0.
Something like struct compressed_format_header {
u8 flag; /* Must be ASCII STX or "\b" */
u8 length;
}
Depends on the config of course, but it could reduce total
image size ~50k on an x86-32 defconfig
Re: [kernel-hardening] Re: [PATCH v1 0/2] Introduce the initify gcc plugin
On Tue, 28 Jun 2016 14:49:15 -0700, Joe Perches said:
> Another potentially useful plugin, especially for embedded systems,
> would be to compress any string literal marked with
>
> __attribute__((format(printf, string-index,)))
>
> and decompress the compressed format on the stack in lib/vsprintf.c
> vsnprintf just before use.
Are there enough such strings in the kernel to make it worth the effort?
I'm assuming that the string literals in printk("some string here") are
automatically so marked?
Is there a minimum length under which the compression overhead actually
makes it larger? For instance, "a" can't be compressed, because you need
to indicate there's 1 "a" and 1 \0, while "aa" can, because you can
express it as '6*"a" 1 \0 in only 4 bytes not 7. But exactly where the
cutoff is, I have no idea (and is probably *very* text-dependent, as
"aa" and "abcdef" will compress differently)
pgpmSe4ChQf0P.pgp
Description: PGP signature
Re: [PATCH v1 0/2] Introduce the initify gcc plugin
On Tue, 2016-06-28 at 13:34 +0200, Emese Revfy wrote: > I would like to introduce the initify gcc plugin. 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. It reduces memory usage. > The initify gcc plugin can be useful for embedded systems. Another potentially useful plugin, especially for embedded systems, would be to compress any string literal marked with __attribute__((format(printf, string-index,))) and decompress the compressed format on the stack in lib/vsprintf.c vsnprintf just before use. I've started to experiment with that.
Re: [kernel-hardening] [PATCH v1 0/2] Introduce the initify gcc plugin
On Tue, Jun 28, 2016 at 9:14 AM, Emese Revfy wrote: > On Tue, 28 Jun 2016 13:57:49 +0100 > Mark Rutland wrote: > >> On Tue, Jun 28, 2016 at 01:34:07PM +0200, Emese Revfy wrote: >> > This patch set is based on the "Add support for complex gcc plugins that >> > don't fit in a single file" patch set (git/kees/linux.git#kspp HEAD: >> > e5d4798b284cd192c8b). >> >> I was hoping to give this a spin on arm/arm64, but I couldn't find the >> prerequisite branch/tag/commit in that tree: >> >> https://git.kernel.org/cgit/linux/kernel/git/kees/linux.git/commit/?id=e5d4798b284cd192c8b >> >> Where should I be looking? > > Sorry, this commit was disappear. You can apply these patches to this tree: > https://github.com/ephox-gcc-plugins/gcc-plugins_linux-next.git (initify > branch) The linux-next tree should have what you need for the plugin support. This is merging from my KSPP tree: https://git.kernel.org/linux/kernel/git/kees/linux.git for-next/kspp -Kees -- Kees Cook Chrome OS & Brillo Security
Re: [PATCH v1 0/2] Introduce the initify gcc plugin
On Tue, 28 Jun 2016 21:02:54 +0200 Rasmus Villemoes wrote: > It'll get placed in multiple sections by the compiler, and nothing bad > happens. String deduplication is something the linker does to sections > equipped with appropriate flags. So in this case that of course means Note that I didn't add such flags to my sections yet, but I have it on my todo list. > that the kernel image itself would be slightly bigger, while the used > data after init would be the same. But I don't think there's a lot of > these cases. (Also, "initfunc" would at least vanish). -- Emese
Re: [PATCH v1 0/2] Introduce the initify gcc plugin
On Tue, 28 Jun 2016 19:00:22 +0200 Mathias Krause wrote: > > section vanilla vanilla + initifychange > > --- > > .rodata 39059688 (0x25400e8)38527210 (0x24be0ea)-532478 > > .data 45744128 (0x2ba)45404160 (0x2b4d000)-339968 > > .init.data 1361144 (0x14c4f8) 1674200 (0x198bd8)+313056 > > .text 77615128 (0x4a05018)77576664 (0x49fb9d8) -38464 > > .init.text 1108455 (0x10e9e7) 1137618 (0x115bd2) +29163 > > You should probably provide numbers for .init.rodata.str, .exit.rodata.str > and .exit.text as well. Otherwise this delta calculation suggests a rather > gigantic image size reduction which is probably not the case ;) init.rodata.str is an input section that merges into the INIT_DATA output section. I didn't make statistics for exit* yet because I have a problem with that (I asked for help in a previous e-mail). > Also a comparison of the final kernel image size would be nice to see if I no longer have the vmlinux images but I saved away the readelf outputs, here's the PT_LOAD size data: FileSiz (vanilla) FileSiz (vanilla+initify) change --- 00 119189504 (0x71ab000) 118657024 (0x7129000) -532480 01 45838336 (0x2bb7000)45498368 (0x2b64000) -339968 032830336 (0x2b3000) 3198976 (0x30d000) +368640 00 .text .text.exit .text.startup .notes __ex_table .rodata __bug_table .pci_fixup .builtin_fw .tracedata __ksymtab __ksymtab_gpl __ksymtab_strings __init_rodata __param __modver 01 .data .fini_array .vvar 03 .init.text .altinstr_aux .init.data .x86_cpu_dev.init .parainstructions .altinstructions .altinstr_replacement .iommu_table .apicdrivers .exit.text .exit.data .smp_locks .bss .brk I think the smaller .data section is wrong, so I'll look into it. -- Emese
Re: [PATCH v1 0/2] Introduce the initify gcc plugin
On Tue, Jun 28 2016, Joe Perches wrote:
>> What happens to string deduplication when one string
>> is in an init function and the same string is also used
>> in a non-init function in the same compilation unit?
>>
>> foo.c
>>
>> __init void initfunc(void)
>> {
>> pr_info("%s: I'm here\n", __func__);
>> }
>>
>> void runtimefunc(void)
>> {
>> pr_info("I'm here: %s\n", __func__);
>> }
>>
>> In what section does the string "I'm here: %s\n" get placed
>> or does it get placed into multiple sections?
It'll get placed in multiple sections by the compiler, and nothing bad
happens. String deduplication is something the linker does to sections
equipped with appropriate flags. So in this case that of course means
that the kernel image itself would be slightly bigger, while the used
data after init would be the same. But I don't think there's a lot of
these cases. (Also, "initfunc" would at least vanish).
Re: [PATCH v1 0/2] Introduce the initify gcc plugin
On Tue, 2016-06-28 at 09:35 -0700, Joe Perches wrote:
> (adding Mathias Krause who did something similar via macros in 2014)
>
> https://lkml.org/lkml/2014/6/22/149
>
> On Tue, 2016-06-28 at 13:34 +0200, Emese Revfy wrote:
> >
> > I would like to introduce the initify gcc plugin. 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. It reduces memory usage.
> > The initify gcc plugin can be useful for embedded systems.
> What happens to string deduplication when one string
> is in an init function and the same string is also used
> in a non-init function in the same compilation unit?
>
> foo.c
>
> __init void initfunc(void)
> {
> pr_info("%s: I'm here\n", __func__);
> }
>
> void runtimefunc(void)
> {
> pr_info("I'm here: %s\n", __func__);
> }
>
> In what section does the string "I'm here: %s\n" get placed
> or does it get placed into multiple sections?
Sorry, Joe can't type.
That was meant to be the identical string in both functions.
Re: [PATCH v1 0/2] Introduce the initify gcc plugin
Hi Emese, On Tue, Jun 28, 2016 at 01:34:07PM +0200, Emese Revfy wrote: > I would like to introduce the initify gcc plugin. 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. It reduces memory usage. > The initify gcc plugin can be useful for embedded systems. > > It is a CII project supported by the Linux Foundation. > > This plugin is the part of grsecurity/PaX. > > The plugin supports all gcc versions from 4.5 to 6.0. > > I made some changes on top of the PaX version (since March 6.). These are > the important ones: > * move all local strings to init.rodata.str and exit.rodata.str >(not just __func__) > * report all initified strings and functions >(GCC_PLUGIN_INITIFY_VERBOSE config option) > * automatically discover init/exit functions and apply the __init or >__exit attributes on them > > You can find more about the changes here: > https://github.com/ephox-gcc-plugins/initify > > This patch set is based on the "Add support for complex gcc plugins that > don't fit in a single file" patch set (git/kees/linux.git#kspp HEAD: > e5d4798b284cd192c8b). > > Some statistics about the plugin: > > On allyes config (amd64, gcc-6): > * 7731 initified strings > * 231 initified functions > > On allmod config (i386, gcc-6): > * 8846 initified strings > * 252 initified functions > > On allyes config (amd64, gcc-6): > > section vanilla vanilla + initifychange > --- > .rodata 39059688 (0x25400e8)38527210 (0x24be0ea)-532478 > .data 45744128 (0x2ba)45404160 (0x2b4d000)-339968 > .init.data 1361144 (0x14c4f8) 1674200 (0x198bd8)+313056 > .text 77615128 (0x4a05018)77576664 (0x49fb9d8) -38464 > .init.text 1108455 (0x10e9e7) 1137618 (0x115bd2) +29163 You should probably provide numbers for .init.rodata.str, .exit.rodata.str and .exit.text as well. Otherwise this delta calculation suggests a rather gigantic image size reduction which is probably not the case ;) Also a comparison of the final kernel image size would be nice to see if the string duplication issue mentioned in [1] is actually an issue. [1] http://marc.info/?l=linux-kernel&m=140364632417795&w=2 Thanks, Mathias > > > Emese Revfy (2): > Add the initify gcc plugin > Mark functions with the __nocapture attribute > > --- > arch/Kconfig | 23 + > arch/arm/include/asm/string.h| 10 +- > arch/arm64/include/asm/string.h | 23 +- > arch/powerpc/include/asm/string.h| 19 +- > arch/x86/boot/string.h |4 +- > arch/x86/include/asm/string_32.h | 21 +- > arch/x86/include/asm/string_64.h | 18 +- > arch/x86/kernel/hpet.c |2 +- > include/asm-generic/bug.h|6 +- > include/asm-generic/vmlinux.lds.h|2 + > include/linux/compiler-gcc.h | 10 +- > include/linux/compiler.h |4 + > include/linux/fs.h |5 +- > include/linux/printk.h |2 +- > include/linux/string.h | 73 +-- > scripts/Makefile.gcc-plugins |4 + > scripts/gcc-plugins/initify_plugin.c | 1147 > ++ > 17 files changed, 1283 insertions(+), 90 deletions(-)
Re: [PATCH v1 0/2] Introduce the initify gcc plugin
(adding Mathias Krause who did something similar via macros in 2014)
https://lkml.org/lkml/2014/6/22/149
On Tue, 2016-06-28 at 13:34 +0200, Emese Revfy wrote:
> I would like to introduce the initify gcc plugin. 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. It reduces memory usage.
> The initify gcc plugin can be useful for embedded systems.
What happens to string deduplication when one string
is in an init function and the same string is also used
in a non-init function in the same compilation unit?
foo.c
__init void initfunc(void)
{
pr_info("%s: I'm here\n", __func__);
}
void runtimefunc(void)
{
pr_info("I'm here: %s\n", __func__);
}
In what section does the string "I'm here: %s\n" get placed
or does it get placed into multiple sections?
Re: [kernel-hardening] [PATCH v1 0/2] Introduce the initify gcc plugin
On Tue, 28 Jun 2016 13:57:49 +0100 Mark Rutland wrote: > On Tue, Jun 28, 2016 at 01:34:07PM +0200, Emese Revfy wrote: > > This patch set is based on the "Add support for complex gcc plugins that > > don't fit in a single file" patch set (git/kees/linux.git#kspp HEAD: > > e5d4798b284cd192c8b). > > I was hoping to give this a spin on arm/arm64, but I couldn't find the > prerequisite branch/tag/commit in that tree: > > https://git.kernel.org/cgit/linux/kernel/git/kees/linux.git/commit/?id=e5d4798b284cd192c8b > > Where should I be looking? Sorry, this commit was disappear. You can apply these patches to this tree: https://github.com/ephox-gcc-plugins/gcc-plugins_linux-next.git (initify branch) -- Emese
Re: [kernel-hardening] [PATCH v1 0/2] Introduce the initify gcc plugin
On Tue, Jun 28, 2016 at 01:34:07PM +0200, Emese Revfy wrote: > I would like to introduce the initify gcc plugin. 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. It reduces memory usage. > The initify gcc plugin can be useful for embedded systems. > > It is a CII project supported by the Linux Foundation. > > This plugin is the part of grsecurity/PaX. > > The plugin supports all gcc versions from 4.5 to 6.0. > > I made some changes on top of the PaX version (since March 6.). These are > the important ones: > * move all local strings to init.rodata.str and exit.rodata.str >(not just __func__) > * report all initified strings and functions >(GCC_PLUGIN_INITIFY_VERBOSE config option) > * automatically discover init/exit functions and apply the __init or >__exit attributes on them > > You can find more about the changes here: > https://github.com/ephox-gcc-plugins/initify > > This patch set is based on the "Add support for complex gcc plugins that > don't fit in a single file" patch set (git/kees/linux.git#kspp HEAD: > e5d4798b284cd192c8b). I was hoping to give this a spin on arm/arm64, but I couldn't find the prerequisite branch/tag/commit in that tree: https://git.kernel.org/cgit/linux/kernel/git/kees/linux.git/commit/?id=e5d4798b284cd192c8b Where should I be looking? Thanks, Mark.
Re: [PATCH v1 0/2] Introduce the initify gcc plugin
On Tue, 28 Jun 2016 13:34:07 +0200 Emese Revfy wrote: > * automatically discover init/exit functions and apply the __init or >__exit attributes on them Hi, I have a question about this. If a function is called by __init and __exit functions as well then I move it to the __exit section. I think this is correct because such a function is available to both __init and __exit functions as well at runtime. However this generates a section mismatch (from scripts/mod/modpost.c) e.g., WARNING: vmlinux.o(.init.text+0x196849): Section mismatch in reference from the function sctp_init() to the function .exit.text:sctp_v4_del_protocol() The function __init sctp_init() references a function __exit sctp_v4_del_protocol(). This is often seen when error handling in the init function uses functionality in the exit path. The fix is often to remove the __exit annotation of sctp_v4_del_protocol() so it may be used outside an exit section. This check was introduced by this commit (588ccd732ba2d): kbuild: add verbose option to Section mismatch reporting in modpost If this move doesn't cause a problem then I would like to keep it because there are a lot of functions that can become __exit and I would like to remove this warning. Thanks -- Emese
[PATCH v1 0/2] Introduce the initify gcc plugin
I would like to introduce the initify gcc plugin. 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. It reduces memory usage. The initify gcc plugin can be useful for embedded systems. It is a CII project supported by the Linux Foundation. This plugin is the part of grsecurity/PaX. The plugin supports all gcc versions from 4.5 to 6.0. I made some changes on top of the PaX version (since March 6.). These are the important ones: * move all local strings to init.rodata.str and exit.rodata.str (not just __func__) * report all initified strings and functions (GCC_PLUGIN_INITIFY_VERBOSE config option) * automatically discover init/exit functions and apply the __init or __exit attributes on them You can find more about the changes here: https://github.com/ephox-gcc-plugins/initify This patch set is based on the "Add support for complex gcc plugins that don't fit in a single file" patch set (git/kees/linux.git#kspp HEAD: e5d4798b284cd192c8b). Some statistics about the plugin: On allyes config (amd64, gcc-6): * 7731 initified strings * 231 initified functions On allmod config (i386, gcc-6): * 8846 initified strings * 252 initified functions On allyes config (amd64, gcc-6): section vanilla vanilla + initifychange --- .rodata 39059688 (0x25400e8)38527210 (0x24be0ea)-532478 .data 45744128 (0x2ba)45404160 (0x2b4d000)-339968 .init.data 1361144 (0x14c4f8) 1674200 (0x198bd8)+313056 .text 77615128 (0x4a05018)77576664 (0x49fb9d8) -38464 .init.text 1108455 (0x10e9e7) 1137618 (0x115bd2) +29163 Emese Revfy (2): Add the initify gcc plugin Mark functions with the __nocapture attribute --- arch/Kconfig | 23 + arch/arm/include/asm/string.h| 10 +- arch/arm64/include/asm/string.h | 23 +- arch/powerpc/include/asm/string.h| 19 +- arch/x86/boot/string.h |4 +- arch/x86/include/asm/string_32.h | 21 +- arch/x86/include/asm/string_64.h | 18 +- arch/x86/kernel/hpet.c |2 +- include/asm-generic/bug.h|6 +- include/asm-generic/vmlinux.lds.h|2 + include/linux/compiler-gcc.h | 10 +- include/linux/compiler.h |4 + include/linux/fs.h |5 +- include/linux/printk.h |2 +- include/linux/string.h | 73 +-- scripts/Makefile.gcc-plugins |4 + scripts/gcc-plugins/initify_plugin.c | 1147 ++ 17 files changed, 1283 insertions(+), 90 deletions(-)
