linux-kernel - Re: linker-tables v5 testing

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] [day] [month] [year] [list]
Date:   Fri, 9 Dec 2016 12:11:13 +1000
From:   Nicholas Piggin <nicholas.piggin@...il.com>
To:     "Luis R. Rodriguez" <mcgrof@...nel.org>
Cc:     Borislav Petkov <bp@...en8.de>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Guenter Roeck <linux@...ck-us.net>,
        Masami Hiramatsu <mhiramat@...nel.org>,
        Namhyung Kim <namhyung@...nel.org>,
        Michael Matz <matz@...e.de>,
        Nicholas Piggin <npiggin@...il.com>,
        David Ahern <dsahern@...il.com>,
        Kees Cook <keescook@...omium.org>,
        Wang Nan <wangnan0@...wei.com>,
        Fengguang Wu <fengguang.wu@...el.com>,
        Jiri Olsa <jolsa@...nel.org>, Arnd Bergmann <arnd@...db.de>,
        Joerg Roedel <joro@...tes.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "H. Peter Anvin" <hpa@...or.com>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        Adrian Hunter <adrian.hunter@...el.com>
Subject: Re: linker-tables v5 testing

On Fri, 2 Dec 2016 07:49:52 -0800
"Luis R. Rodriguez" <mcgrof@...nel.org> wrote:

> On Thu, Dec 1, 2016 at 10:31 PM, Nicholas Piggin
> <nicholas.piggin@...il.com> wrote:
> >
> > On 2 Dec 2016 2:35 AM, "Luis R. Rodriguez" <mcgrof@...nel.org> wrote:  
> >>
> >> On Wed, Nov 30, 2016 at 9:20 PM, Nicholas Piggin <npiggin@...il.com>
> >> wrote:  
> >> > On Thu, 1 Dec 2016 16:04:30 +1100
> >> > Nicholas Piggin <npiggin@...il.com> wrote:
> >> >  
> >> >> On Wed, 30 Nov 2016 19:15:27 -0800
> >> >> "Luis R. Rodriguez" <mcgrof@...nel.org> wrote:
> >> >>  
> >> >> > On Wed, Nov 30, 2016 at 6:51 PM, Nicholas Piggin <npiggin@...il.com>
> >> >> > wrote:  
> >> >> > > On Wed, 30 Nov 2016 18:38:16 +0100
> >> >> > > "Luis R. Rodriguez" <mcgrof@...nel.org> wrote:
> >> >> > >  
> >> >> > >> On Wed, Nov 30, 2016 at 02:09:47PM +1100, Nicholas Piggin wrote:  
> >> >>  
> >> >> > >> What is wrong with that ? Separating linker table and section
> >> >> > >> ranges is  
> >> >> > >
> >> >> > > It's not that you separate those, of course you need that. It's
> >> >> > > that
> >> >> > > you also separate other sections from the input section
> >> >> > > descriptions:
> >> >> > >
> >> >> > > -               *(.text.hot .text .text.fixup .text.unlikely)
> >> >> > > \
> >> >> > > +               *(.text.hot .text)
> >> >> > > \
> >> >> > > +               *(SORT(.text.rng.*))
> >> >> > > \
> >> >> > > +               *(.text.fixup .text.unlikely)
> >> >> > > \  
> >> >
> >> > Ahh, you're doing it to avoid clash with compiler generated sections.  
> >>
> >> Nope, its for two reasons:
> >>
> >> 1) To be able to construct arrays without modifying the linker script
> >> we had to get crafty, and opted in for the trick of picking two
> >> arbitrary delimiters for use of section start, and section end, namely
> >> the tilde character ("~") and the empty string (""), and then stuffing
> >> anything in between. For this to work properly we must SORT() these
> >> specially crafted sections as well.
> >>
> >> 2) Because I don't want to regress .text if SORT()'ing it breaks
> >> something. In theory it should not but I rather be careful.  
> >
> > Oh yes I wasn't talking about the sort itself, but about why you broke up
> > the existing input section descriptions.  
> 
> Ah, but I was also talking about this, the only thing is...
> 
> > That was my only concern, e.g.,
> > .data and .data.[_0-9a-zA-Z] spoke be in the same description.  
> 
> I was talking about splitting up .data and both .data.tbl .data.rng --
> you were talking specifically only about .data and .data.[_0-9a-zA-Z]
> and now I see the concern! Yes, you are -- we can avoid this, its just
> your glob would also capture .data.tbl and data.rng and I want to sort
> these so I do it first. But as you already deduced, this should still
> have no harm as I am just stuffing it in well sorted first and the
> later glob just captures that. I could have just used .data..tbl and
> data..rng as you noted. Either way is fine by me.
> 
> Do you have a preference?

I would say use "..", just so there is less ambiguity and more
flexibility in moving around the input section descriptions if needed.

> 
> >> > The usual way to cope with that seems to be to use two dots for your
> >> > name.
> >> > .text..rng.*  
> >>
> >> I have been wondering why people started doing that, it was not clear
> >> nor documented anywhere. So no, it was not my original motivation, but
> >> if it helps, it will be good to document this as well.  
> >
> > Yeah it's convention because . can be part of a section name but not a C
> > symbol.  
> 
> Great, makes sense -- do you have references for this practice BTW or
> did you just infer this?

I believe I've seen something, perhaps it was in the binutils manuals,
but I tried just now and couldn't find anything.

It is a common practice to use dots in labels to avoid clashes with C
names in general. Specifically for sections we already have some cases
in there which I believe were added for similar reasons.

Thanks,
Nick