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

Groups > linux.kernel > #1432880 > unrolled thread

[PATCH v1 0/2] Introduce the initify gcc plugin

Back to article view | Back to linux.kernel

Contents

  [PATCH v1 0/2] Introduce the initify gcc plugin Emese Revfy <re.emese@gmail.com> - 2016-06-28 13:30 +0200
    [PATCH v1 2/2] Mark functions with the __nocapture attribute Emese Revfy <re.emese@gmail.com> - 2016-06-28 13:40 +0200
      Re: [PATCH v1 2/2] Mark functions with the __nocapture attribute Joe Perches <joe@perches.com> - 2016-06-28 18:50 +0200
        Re: [PATCH v1 2/2] Mark functions with the __nocapture attribute Emese Revfy <re.emese@gmail.com> - 2016-06-28 22:40 +0200
          Re: [PATCH v1 2/2] Mark functions with the __nocapture attribute Joe Perches <joe@perches.com> - 2016-06-28 23:10 +0200
            Re: [PATCH v1 2/2] Mark functions with the __nocapture attribute Emese Revfy <re.emese@gmail.com> - 2016-06-29 20:50 +0200
              Re: [PATCH v1 2/2] Mark functions with the __nocapture attribute Joe Perches <joe@perches.com> - 2016-06-30 02:20 +0200
                Re: [PATCH v1 2/2] Mark functions with the __nocapture attribute Emese Revfy <re.emese@gmail.com> - 2016-07-01 16:00 +0200
      Re: [PATCH v1 2/2] Mark functions with the __nocapture attribute Rasmus Villemoes <linux@rasmusvillemoes.dk> - 2016-06-28 23:00 +0200
        Re: [PATCH v1 2/2] Mark functions with the __nocapture attribute "PaX Team" <pageexec@freemail.hu> - 2016-06-28 23:50 +0200
          Re: [PATCH v1 2/2] Mark functions with the __nocapture attribute Rasmus Villemoes <linux@rasmusvillemoes.dk> - 2016-06-29 00:50 +0200
        Re: [PATCH v1 2/2] Mark functions with the __nocapture attribute Emese Revfy <re.emese@gmail.com> - 2016-06-29 20:40 +0200
    Re: [PATCH v1 0/2] Introduce the initify gcc plugin Emese Revfy <re.emese@gmail.com> - 2016-06-28 13:40 +0200
    [PATCH v1 1/2] Add the initify gcc plugin Emese Revfy <re.emese@gmail.com> - 2016-06-28 13:40 +0200
      Re: [PATCH v1 1/2] Add the initify gcc plugin Rasmus Villemoes <linux@rasmusvillemoes.dk> - 2016-06-28 23:10 +0200
        Re: [PATCH v1 1/2] Add the initify gcc plugin Kees Cook <keescook@chromium.org> - 2016-06-29 17:00 +0200
        Re: [PATCH v1 1/2] Add the initify gcc plugin Emese Revfy <re.emese@gmail.com> - 2016-06-29 21:10 +0200
    Re: [kernel-hardening] [PATCH v1 0/2] Introduce the initify gcc  plugin Mark Rutland <mark.rutland@arm.com> - 2016-06-28 15:00 +0200
      Re: [kernel-hardening] [PATCH v1 0/2] Introduce the initify gcc  plugin Emese Revfy <re.emese@gmail.com> - 2016-06-28 18:10 +0200
        Re: [kernel-hardening] [PATCH v1 0/2] Introduce the initify gcc plugin Kees Cook <keescook@chromium.org> - 2016-06-28 22:50 +0200
          Re: [kernel-hardening] [PATCH v1 0/2] Introduce the initify gcc  plugin Mark Rutland <mark.rutland@arm.com> - 2016-06-29 10:30 +0200
            Re: [kernel-hardening] [PATCH v1 0/2] Introduce the initify gcc  plugin Mark Rutland <mark.rutland@arm.com> - 2016-06-29 20:00 +0200
              Re: [kernel-hardening] [PATCH v1 0/2] Introduce the initify gcc  plugin Emese Revfy <re.emese@gmail.com> - 2016-06-29 20:30 +0200
    Re: [PATCH v1 0/2] Introduce the initify gcc plugin Joe Perches <joe@perches.com> - 2016-06-28 18:40 +0200
      Re: [PATCH v1 0/2] Introduce the initify gcc plugin Joe Perches <joe@perches.com> - 2016-06-28 20:50 +0200
        Re: [PATCH v1 0/2] Introduce the initify gcc plugin Rasmus Villemoes <linux@rasmusvillemoes.dk> - 2016-06-28 21:10 +0200
          Re: [PATCH v1 0/2] Introduce the initify gcc plugin Emese Revfy <re.emese@gmail.com> - 2016-06-28 22:30 +0200
    Re: [PATCH v1 0/2] Introduce the initify gcc plugin Mathias Krause <minipli@ld-linux.so> - 2016-06-28 19:10 +0200
      Re: [PATCH v1 0/2] Introduce the initify gcc plugin Emese Revfy <re.emese@gmail.com> - 2016-06-28 22:30 +0200
    Re: [PATCH v1 0/2] Introduce the initify gcc plugin Joe Perches <joe@perches.com> - 2016-06-29 00:00 +0200
      Re: [kernel-hardening] Re: [PATCH v1 0/2] Introduce the initify gcc plugin Valdis.Kletnieks@vt.edu - 2016-06-29 00:10 +0200
        Re: [kernel-hardening] Re: [PATCH v1 0/2] Introduce the initify gcc  plugin Joe Perches <joe@perches.com> - 2016-06-29 02:00 +0200

Page 2 of 2 — ← Prev page 1 [2]

#1433553 — 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 <re.emese@gmail.com> wrote:
> > On Tue, 28 Jun 2016 13:57:49 +0100
> > Mark Rutland <mark.rutland@arm.com> 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.

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

#1433929 — 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 <re.emese@gmail.com> wrote:
> > > On Tue, 28 Jun 2016 13:57:49 +0100
> > > Mark Rutland <mark.rutland@arm.com> 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.

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

#1433958 — Re: [kernel-hardening] [PATCH v1 0/2] Introduce the initify gcc plugin

On Wed, 29 Jun 2016 18:52:27 +0100
Mark Rutland <mark.rutland@arm.com> 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 <re.emese@gmail.com> wrote:
> > > > On Tue, 28 Jun 2016 13:57:49 +0100
> > > > Mark Rutland <mark.rutland@arm.com> 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

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

#1433105

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

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

#1433208

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.

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

#1433219

On Tue, Jun 28 2016, Joe Perches <joe@perches.com> 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).

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

#1433280

On Tue, 28 Jun 2016 21:02:54 +0200
Rasmus Villemoes <linux@rasmusvillemoes.dk> 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

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

#1433144

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 + initify        change
> -----------------------------------------------------------------------
> .rodata         39059688 (0x25400e8)    38527210 (0x24be0ea)    -532478
> .data           45744128 (0x2ba0000)    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(-)

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

#1433275

On Tue, 28 Jun 2016 19:00:22 +0200
Mathias Krause <minipli@ld-linux.so> wrote:

> > section         vanilla                 vanilla + initify        change
> > -----------------------------------------------------------------------
> > .rodata         39059688 (0x25400e8)    38527210 (0x24be0ea)    -532478
> > .data           45744128 (0x2ba0000)    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
03        2830336  (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

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

#1433344

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.

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

#1433347 — Re: [kernel-hardening] Re: [PATCH v1 0/2] Introduce the initify gcc plugin

[Multipart message — attachments visible in raw view] — view raw

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 "aaaaaa" 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
"aaaaaa" and "abcdef" will compress differently....)

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

#1433374 — Re: [kernel-hardening] Re: [PATCH v1 0/2] Introduce the initify gcc plugin

On Tue, 2016-06-28 at 18:07 -0400, Valdis.Kletnieks@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

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.kernel

csiph-web