linux-kernel - Re: [PATCH v3 1/3] Make section names compatible with -ffunction-sections -fdata-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]

Date:	Sun, 26 Apr 2009 11:09:06 +0200
From:	Sam Ravnborg <sam@...nborg.org>
To:	Tim Abbott <tabbott@....EDU>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Linux kernel mailing list <linux-kernel@...r.kernel.org>,
	Anders Kaseorg <andersk@....edu>,
	Waseem Daher <wdaher@....edu>,
	Denys Vlasenko <vda.linux@...glemail.com>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Andi Kleen <andi@...stfloor.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	Jeff Arnold <jbarnold@....edu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Jon Masters <jonathan@...masters.org>,
	Masami Hiramatsu <mhiramat@...hat.com>,
	Theodore Ts'o <tytso@....edu>,
	Nikanth Karthikesan <knikanth@...e.de>,
	Arjan van de Ven <arjan@...radead.org>,
	Paul Mundt <lethal@...ux-sh.org>,
	Américo Wang <xiyou.wangcong@...il.com>
Subject: Re: [PATCH v3 1/3] Make section names compatible with -ffunction-sections -fdata-sections

On Sat, Apr 25, 2009 at 10:10:38PM -0400, Tim Abbott wrote:
> On Fri, 24 Apr 2009, Sam Ravnborg wrote:
> 
> > This patch touches far too many files.
> > We should try to work out a method so we are in better control
> > of the section names, so renaming in the end is a simple patch
> > touching only a few files.
> 
> OK, I'm now planning to implement this approach.
> 
> > > -.section .text.head, "ax"
> > > +.section .text..head, "ax"
> > 
> > Use __HEAD (from include/linux/init.h)
> > Same goes for all other uses of .text.head.
> 
> I notice that __HEAD uses .head.text, while some architectures use 
> .text.head.  It looks like this is just an inconsistency across 
> architectures that will be removed as a consequence of this cleanup work 
> (no architecture uses both .head.text and .text.head).
Correct - this is implied by the introduction of __HEAD.
For users of the old naming schme (like i386) you need to adjust the
linker script too.

> One challenge with this approach is that many linker scripts use these 
> section names in more complex ways than just squashing HEAD_TEXT at the 
> start of the text section.  For example, the the linker scripts for x86 
> and ia64 have code like:
> 
>   .text.head : AT(ADDR(.text.head) - LOAD_OFFSET) {
>         _text = .;                      /* Text and read-only data */
>         *(.text.head)
>   } :text = 0x9090
> 
> which can't user either the __HEAD macro (which is the full .section line) 
> or the HEAD_TEXT macro (which is the *(.head.text)).

The simple way to deal wi8th this is to accept some duplication of naming
in order to keep readability.
So I suggest you to use:

  .head.text : AT(ADDR(.head.text) - LOAD_OFFSET) {
        _text = .;                      /* Text and read-only data */
        HEAD_TEXT
  } :text = 0x9090

We need to be carefull about keeping some sort of readability
of these linker macro files.

I was not specific in my last mail about this - but I assume you have
understood that the naming ".head.text" was selected so it is compatible
wiht -ffunction-sections. In other words no need for any ugly ".." here.

We should try to be as consistent as possible across architectures here
so it is better to toach a few additiona files rather than adding macros
and the like to accept there sub-optimal section naming.

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