[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <47053.1467151621@turing-police.cc.vt.edu>
Date: Tue, 28 Jun 2016 18:07:01 -0400
From: Valdis.Kletnieks@...edu
To: kernel-hardening@...ts.openwall.com
Cc: Emese Revfy <re.emese@...il.com>,
Matt Davis <mattdavis9@...il.com>, pageexec@...email.hu,
spender@...ecurity.net, mmarek@...e.com, keescook@...omium.org,
linux-kernel@...r.kernel.org, yamada.masahiro@...ionext.com,
linux-kbuild@...r.kernel.org, minipli@...linux.so,
linux@...linux.org.uk, catalin.marinas@....com,
linux@...musvillemoes.dk, david.brown@...aro.org,
benh@...nel.crashing.org, tglx@...utronix.de,
akpm@...ux-foundation.org, jlayton@...chiereds.net, arnd@...db.de
Subject: 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 "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....)
Content of type "application/pgp-signature" skipped
Powered by blists - more mailing lists