linux-kernel - Re: [PATCHv3 0/9] 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]

Message-ID: <1408897738.20683.14.camel@joe-AO725>
Date:	Sun, 24 Aug 2014 09:28:58 -0700
From:	Joe Perches <joe@...ches.com>
To:	Mathias Krause <minipli@...glemail.com>
Cc:	Sam Ravnborg <sam@...nborg.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Rasmus Villemoes <linux@...musvillemoes.dk>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCHv3 0/9] Mark literal strings in __init / __exit code

On Sun, 2014-08-24 at 18:04 +0200, Mathias Krause wrote:
> On 21 August 2014 18:25, Sam Ravnborg <sam@...nborg.org> wrote:
> > So is it really worth it?
> 
> I took the hacky script mentioned in the first email (now also
> attached, init_str.awk), let it ran over the whole kernel, fixed the
> fall-out and did an allmodconfig build. Beside the script being far
> from perfect (it catches a few false positives and, more important,
> only covers a fraction of the potential strings -- only the pr_*()
> macros) it already leads to 24 modules requiring a page less during
> run-time because of the afore mentioned page crossing. It includes
> popular modules like hid.ko and ipv6.ko, so almost anybody would
> benefit from it. But as the page crossing effect depends on the
> particular kernel configuration and toolchain setup, fell free to do
> your own tests. The script doing the measurement is attached, too
> (mod_info.sh)

I think it would be worth it.

I think the added complexity converting:
	printk/pr_<level>
to
	pi_<level>/pe_<level>
for init/exit sections is a lightweight, one-time cost and
continuing upstream maintainer involvement is next to nil.

This mechanism supports all existing compiler toolchains.

Updating toolchains and or using a gcc compiler plugin
means that extra work would also need to be done for llvm
and any other alternate compiler.

And, as Mathias mentioned, the string deduplication logic
may be somewhat complicated for each compiler.

The worst that happens if a printk is added that is not
written as pi_<level> is some unnecessary .text is consumed.

No doubt someone will every so often run Mathias' scripts
against the kernel tree and submit the odd patch to fix it
up.


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