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: <Pine.LNX.4.64N.0710231758070.8693@blysk.ds.pg.gda.pl>
Date:	Tue, 23 Oct 2007 18:23:33 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@...ux-mips.org>
To:	Sam Ravnborg <sam@...nborg.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, 12 Oct 2007, Sam Ravnborg wrote:

> What is the actual benefit here expressed in real numbers?
> For the __init/__exit notation that is yet only partially correct
> we often see corner cases where one ask if it is really worth it.
> Adding the discard functionality for strings seems like a logical extension
> but there is a benefit/pain ratio to consider.
> 
> So real numbers please.

 I have quoted some -- if you need more (I have left out all the 
non-allocatable sections for clarity):

$ mipsel-linux-readelf -S drivers/net/defxx.o
There are 26 section headers, starting at offset 0x3484:

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 1] .text             PROGBITS        00000000 000040 0022a0 00  AX  0   0 16
  [ 3] .data             PROGBITS        00000000 0022e0 0000f0 00  WA  0   0 16
  [ 5] .bss              NOBITS          00000000 0023d0 000010 00  WA  0   0 16
  [ 6] .reginfo          MIPS_REGINFO    00000000 0023d0 000018 18   A  0   0  4
  [10] .exit.text        PROGBITS        00000000 002748 0000ec 00  AX  0   0  4
  [12] .init.text        PROGBITS        00000000 002834 000460 00  AX  0   0  4
  [14] .rodata.str1.4    PROGBITS        00000000 002c94 0004a4 01 AMS  0   0  4
  [15] .rodata           PROGBITS        00000000 003140 000080 00   A  0   0 16
  [17] .exitcall.exit    PROGBITS        00000000 0031c0 000004 00  WA  0   0  4
  [19] .initcall6.init   PROGBITS        00000000 0031c4 000004 00  WA  0   0  4
  [21] .init.str1        PROGBITS        00000000 0031c8 0001e0 01 AMS  0   0  4
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings)
  I (info), L (link order), G (group), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor specific)

So with a quick calculation (`size' unfortunately gives confusing 
numbers): text is 10220 (init 1120, exit 236), data is 2044 and bss is 16 
bytes.  What you gain with this change is the space occupied by the 
.init.str1 section, worth 480 bytes, which would otherwise be resident.

> 1) We want to consolidate this in include/asm-generic/vmlinux*
> somehow and this should be doen as a separate step.

 Arguably all the existing linker scripts should be made more consistent I 
suppose.  Currently all the {init,exit} annotations are handled separately 
by each architecture, so this would be no exception.  If you have a 
proposal as to how to do it cleanly, people will certainly appreciate it.

> 2) If we introduce discardable strings then we shall in parallel
> add build time checks so we catch strings marked as discardable
> which is used outside a discardable compatible function.

 Well, `modpost' should already be taking care of this -- __init_begin and 
__init_end are defined for this purpose.

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