linux-kernel - Re: [RFC PATCH 0/3] Mark literal strings in __init / _

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]

Date:	Wed, 25 Jun 2014 00:48:31 -0700
From:	Joe Perches <joe@...ches.com>
To:	Rasmus Villemoes <linux@...musvillemoes.dk>
Cc:	Mathias Krause <minipli@...glemail.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [RFC PATCH 0/3] Mark literal strings in __init / __exit code

On Wed, 2014-06-25 at 09:35 +0200, Rasmus Villemoes wrote:

> yes, the source would need
> to be annotated some way or other, or gcc would need to learn the
> semantics of certain kernel functions.
> 
> Speaking of dangling pointers: A similar disaster would happen if some
> code containing pi_* calls gets copy-pasted to some non-__init
> function.

This is my biggest issue with adding these new,
somewhat obscure macros.

> Could checkpatch learn to warn about calling these functions
> from the wrong context?

It's not possible.  checkpatch works on patch chunks.
Any patch chunk may not contain the function attributes.

> Mathias Krause <minipli@...glemail.com> writes:
> 
> > Merging strings across multiple compilation units does not happen,
> > anyway -- not now, not with the new macros.
> 
> Certainly string merging seems to happen, at least at -O1 and higher:
> 
> $ grep . *.c
> a.c:const char *a(void) { return "654321"; }
> b.c:const char *b(void) { return "4321"; }
> c.c:const char *c(void) { return "654321"; }
> main.c:#include <stdio.h>
> main.c:const char *a(void);
> main.c:const char *b(void);
> main.c:const char *c(void);
> main.c:int main(void)
> main.c:{
> main.c: printf("%p\n", a());
> main.c: printf("%p\n", b());
> main.c: printf("%p\n", c());
> main.c: return 0;
> main.c:}
> $ gcc -O1 -c a.c && gcc -O1 -c b.c && gcc -O1 -c c.c
> $ gcc -O1 main.c a.o b.o c.o
> $ ./a.out 
> 0x400630
> 0x400632
> 0x400630
> 
> So not only are identical strings merged; suffixes are also optimized.

Yup.  Nice example.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/