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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ