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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1467158049.24287.90.camel@perches.com>
Date:	Tue, 28 Jun 2016 16:54:09 -0700
From:	Joe Perches <joe@...ches.com>
To:	Valdis.Kletnieks@...edu, 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, 2016-06-28 at 18:07 -0400, Valdis.Kletnieks@...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