linux-kernel - Re: [PATCH] Discardable strings for init and exit sections

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: <20071012171938.GB6476@stusta.de>
Date:	Fri, 12 Oct 2007 19:19:38 +0200
From:	Adrian Bunk <bunk@...nel.org>
To:	"Maciej W. Rozycki" <macro@...ux-mips.org>
Cc:	Franck Bui-Huu <vagabon.xyz@...il.com>,
	Ralf Baechle <ralf@...ux-mips.org>, linux-arch@...r.kernel.org,
	linux-mips@...ux-mips.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Discardable strings for init and exit sections

On Fri, Oct 12, 2007 at 05:50:01PM +0100, Maciej W. Rozycki wrote:

>  We currently have infrastructure for discardable text and data, but no 
> such thing for strings.  This is especially notable for inline strings 
> such as ones used by printk() which are left behind resident in the memory 
> throughout the life of the system even though code referring to them has 
> been removed.
> 
>  Following a short discussion at the linux-mips list, here is a proposed 
> implementation for discardable strings.  It adds __initstr and __exitstr 
> plus most of the usual variations, but most importantly it adds wrapper 
> macros that may be used for inline strings that make them be put in
> separate sections which may then be discarded, while still preserving the 
> usual merging property of sections containing strings.  The macros are 
> called _i() and _e(), with the other alternatives adding at most two 
> letters each.  This has been inspired by how the GNU gettext handles 
> localised strings in a way that does not add too much clutter and the 
> result is still reasonably well readable.  Some use examples have been 
> included in <linux/init.h>.
>...

I have an objection against this approach:

Our __*init*/__*exit* annotations are already a constant source of bugs, 
and adding more pifalls (e.g. forgotten removal of _i()/_e() when a 
function is no longer __*init*/__*exit*) doesn't sound like a good plan.

Shouldn't it be possible to automatically determine where to put the 
strings? I don't know enough gcc/ld voodoo for being able to tell 
whether it is currently possible, and if yes how, but doing it 
automatically sounds like the only solution that wouldn't result in an
unmaintainable mess.

Ideally, even the current annotations might one day no longer be 
required and replaced with some way to express things like "everything 
only required by module_init() can be __init".

cu
Adrian

BTW: Please add diffstat output when sending patches.

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

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