linux-kernel - Re: [GIT PULL] Modules updates for v5.12

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:   Thu, 25 Feb 2021 17:19:27 +0100
From:   Rasmus Villemoes <rasmus.villemoes@...vas.dk>
To:     Masahiro Yamada <masahiroy@...nel.org>
Cc:     Jessica Yu <jeyu@...nel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Christoph Hellwig <hch@....de>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Miroslav Benes <mbenes@...e.cz>,
        Emil Velikov <emil.l.velikov@...il.com>
Subject: Re: [GIT PULL] Modules updates for v5.12

On 25/02/2021 16.49, Masahiro Yamada wrote:
> On Thu, Feb 25, 2021 at 4:36 AM Rasmus Villemoes
> <rasmus.villemoes@...vas.dk> wrote:
>>
>> On 24/02/2021 15.40, Masahiro Yamada wrote:
> 
> 
> Good insight.
> Actually, I came up with the same idea last night, and had started
> the implementation background.
> I needed sleep before completing the patch set, but
> now it is working as far as I tested.
> 
> BTW,
> KEEP(*(SORT(___ksymtab+foo ___ksymtab+bar ___ksymtab+baz))
> is a syntax error.
> 

ah, ok, didn't test anything, just threw it out there in case somebody
wanted to see if it was doable.

Is that a limitation of SORT? The ld docs say

   There are two ways to include more than one section:
     *(.text .rdata)
     *(.text) *(.rdata)
The difference between these is the order in which the '.text' and
'.rdata' input sections will appear in the output section.

so there shouldn't be a problem mentioning more than one section name?

>> If LD_DEAD_CODE_DATA_ELIMINATION was more widely supported (and I was
>> surprised to see that it's not even available on arm or x86) one could
>> also play another game, dropping the KEEP()s and instead create a linker
>> script snippet containing EXTERN(__ksymtab_foo __ksymtab_bar ...),
>> referencing the "struct kernel_symbol" elements themselves rather than
>> the singleton sections they reside in.
> 
> Do you mean LD_DEAD_CODE_DATA_ELIMINATION must be enabled by default
> to do this?
> 

No, but without LD_DEAD_CODE_DATA_ELIMINATION, I don't see much point of
the TRIM_UNUSED_KSYMS. Yes, the export_symbol metadata itself vanishes,
but the actual functions remain in the image. Conversely, with modules
enabled, LD_DEAD_CODE_DATA_ELIMINATION can't do much when almost all of
the kernel can be built modular so almost extern interface is an
EXPORT_SYMBOL. At least, that's what I see for a ppc target with a
somewhat trimmed-down .config, combining the two gives much more space
saving than the sum of what each option does:

$ size vmlinux.{vanilla,trim,dead,trim-dead}
   text    data     bss     dec     hex filename
6197380 1159488  121732 7478600  721d48 vmlinux.vanilla
6045906 1159440  121732 7327078  6fcd66 vmlinux.trim
6087316 1137284  120476 7345076  7013b4 vmlinux.dead
5675370 1101964  115180 6892514  692be2 vmlinux.trim-dead

Anyway, that was just an aside, probably the above ___ksymtab+foo thing
will work just fine.

Rasmus