linux-kernel - Re: [PATCH] export.h: reduce __ksymtab_strings string duplication by using "MS" section flags

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: <CAK7LNAT=+VMTpK3nBy3J-M9idf8MBi4dB4WKexYatiV2pNHvMg@mail.gmail.com>
Date:   Fri, 22 Nov 2019 20:44:17 +0900
From:   Masahiro Yamada <yamada.masahiro@...ionext.com>
To:     Jessica Yu <jeyu@...nel.org>
Cc:     Rasmus Villemoes <linux@...musvillemoes.dk>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Matthias Maennich <maennich@...gle.com>,
        Arnd Bergmann <arnd@...db.de>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Will Deacon <will@...nel.org>,
        Catalin Marinas <catalin.marinas@....com>
Subject: Re: [PATCH] export.h: reduce __ksymtab_strings string duplication by
 using "MS" section flags

On Fri, Nov 22, 2019 at 1:09 AM Jessica Yu <jeyu@...nel.org> wrote:
>
> +++ Rasmus Villemoes [21/11/19 11:51 +0100]:
> >On 20/11/2019 15.51, Jessica Yu wrote:
> >>
> >> We can alleviate this situation by utilizing the SHF_MERGE and
> >> SHF_STRING section flags. SHF_MERGE|SHF_STRING indicate to the linker
> >> that the data in the section are null-terminated strings
> >
> >[pet peeve: nul, not null.]
>
> Ah, right you are!
>
> >> As of v5.4-rc5, the following statistics were gathered with x86
> >> defconfig with approximately 10.7k exported symbols.
> >>
> >> Size of __ksymtab_strings in vmlinux:
> >> -------------------------------------
> >> v5.4-rc5: 213834 bytes
> >> v5.4-rc5 with commit c3a6cf19e695: 224455 bytes
> >> v5.4-rc5 with this patch: 205759 bytes
> >>
> >> So, we already see memory savings of ~8kB compared to vanilla -rc5 and
> >> savings of nearly 18.7kB compared to -rc5 with commit c3a6cf19e695 on top.
> >
> >Yippee :) Thanks for picking up the ball and sending this.
>
> And thanks for the idea in the first place :-)
>
> >>  /*
> >> - * note on .section use: @progbits vs %progbits nastiness doesn't matter,
> >> - * since we immediately emit into those sections anyway.
> >> + * note on .section use: we specify @progbits vs %progbits since usage of
> >> + * "M" (SHF_MERGE) section flag requires it.
> >>   */
> >> +
> >> +#ifdef CONFIG_ARM
> >> +#define ARCH_PROGBITS %progbits
> >> +#else
> >> +#define ARCH_PROGBITS @progbits
> >> +#endif
> >
> >Did you figure out a way to determine if ARM is the only odd one? I was
> >just going by gas' documentation which mentions ARM as an example, but
> >doesn't really provide a way to know what each arch uses. I suppose 0day
> >will tell us shortly.
>
> I *think* so. At least, I was going off of
> drivers/base/firmware_loader/builtin/Makefile and
> scripts/recordmcount.pl, which were the only other places that I found
> that reference the %progbits vs @progbits oddity. They only use
> %progbits in the case of CONFIG_ARM and @progbits for other
> arches. I wasn't sure about arm64, but I looked at the assembly files
> gcc produced and it looked like @progbits was used there. Added some
> arm64 people to CC since they would know :-)
>
> >If we want to avoid arch-ifdefs in these headers (and that could become
> >unwieldy if ARM is not the only one) I think one could add a
> >asm-generic/progbits.h, add progbits.h to mandatory-y in
> >include/asm-generic/Kbuild, and then just provide a progbits.h on ARM
> >(and the other exceptions) - then I think the kbuild logic automatically
> >makes "#include <asm/progbits.h>" pick up the right one. And the header
> >could define ARCH_PROGBITS with or without the double quotes depending
> >on __ASSEMBLY__.
>
> I think this would work, and it feels like the more correct solution
> especially if arm isn't the only one with the odd progbits char. It
> might be overkill if it's just arm that's affected though. I leave it
> to Masahiro to see what he prefers.
>


BTW, is there any reason why
not use %progbits all the time?


include/linux/init.h hard-codes %progbits

   #define __INITDATA .section ".init.data","aw",%progbits
   #define __INITRODATA .section ".init.rodata","a",%progbits


So, my understanding is '%' works for all architectures,
but it is better to ask 0-day bot to test it.



-- 
Best Regards
Masahiro Yamada