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:	Sun, 22 Jun 2014 15:56:02 -0700
From:	Joe Perches <joe@...ches.com>
To:	Mathias Krause <minipli@...glemail.com>
Cc:	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>, Jason Baron <jbaron@...hat.com>
Subject: Re: [RFC PATCH 0/3] Mark literal strings in __init / __exit code

On Mon, 2014-06-23 at 00:46 +0200, Mathias Krause wrote:
> This RFC series tries to address the problem of dangling strings of
> __init functions after initialization, as well as __exit strings for
> code not even included in the final kernel image. The code might get
> freed, but the format strings are not.
> 
> One solution to the problem might be to declare variables in the code
> and mark those variables as __initconst. That, though, makes the code
> ugly, as can be seen, e.g., in drivers/hwmon/w83627ehf.c -- a pile of
> 'static const char[] __initconst' lines just for the pr_info() call.
> 
> To be able to mark strings easily patch 1 adds macros to init.h to do so
> without the need to explicitly define variables in the code. Internally
> it'll declare ones nonetheless, as this seem to be the only way to
> attach an __attribute__() to a verbatim string. That's already enough to
> solve the problem -- mark the corresponding stings by using these
> macros. But patch 2 adds some syntactical sugar for the most popular use
> case, by providing pr_<level> alike macros, namely pi_<level> for __init
> code and pe_<level> for __exit code. This hides the use of the marker
> macros behind the commonly known printing functions -- with just a
> single character changed.
> 
> Patch 3 exemplarily changes all strings and format strings in
> arch/x86/kernel/acpi/boot.c to use the new macros. It also addresses a
> few styling issues, though. But this already leads to ~1.7 kB of r/o
> data moved to the .init.rodata section, marking it for release after
> init.
> 
> 
> Open issues with this approach:
> 
> 1/ When CONFIG_DYNAMIC_DEBUG is enabled, pi_debug() and pe_debug()
> fall-back to pr_debug() as there is currently no way of removing the
> dynamic entries from the dynamic debug code after init.
> 
> 2/ The variables used in the macros of patch 1 will pollute the symtab
> with unneeded entries. That'll be a problem in the KALLSYMS_ALL case
> only, though. But the symtab will be huge then, anyway. However,
> filtering those even in this case might be desirable.
> 
> 3/ It only seamlessly integrates for the pr_<level>() kind of use cases.
> For other literal strings it gets slightly less readable, e.g. this:
> 
>    strncmp(str, "s4_nohwsig", 10)
> 
> becomes this:
> 
>    strncmp(str, __init_str("s4_nohwsig"), 10)
> 
> That might be okay, though, as it marks the string clearly as an init
> string, so might actually increase the understanding of the life time of
> the string literal.
> 
> 
> So, is there interest in having such macros and markings? Patch 3 shows,
> that there's actual value in it. A hacked up script, dully changing
> pr_<level> to pi_<level> for __init functions under arch/x86/ already is
> able to move ~8kB of r/o data into the .init section. The script,
> though, is dump. It does not handle any of the printk() calls, nor does
> it handle panic() calls or other strings used only in initialization
> code. So there's more to squeeze out. I just want to get some feedback
> first.
> 
> Also documentation of the new macros is missing, maybe even a
> checkpatch.pl change to propose using the new macros instead of pr_*()
> or plain printk() in __init / __exit functions.
> 
> What do you think?

I once proposed a similar thing.

https://lkml.org/lkml/2009/7/21/421

Matt Mackall replied

https://lkml.org/lkml/2009/7/21/463


--
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/