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-next>] [day] [month] [year] [list]

Message-ID: <CAB=NE6UpmbQXbRpua2p8KKRspVzb8GtuNG8JrAN69t79-xU86g@mail.gmail.com>
Date:   Fri, 2 Dec 2016 07:49:52 -0800
From:   "Luis R. Rodriguez" <mcgrof@...nel.org>
To:     Nicholas Piggin <nicholas.piggin@...il.com>
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 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?

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

 Luis