linux-kernel - Re: Linux 6.1-rc3

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:   Tue, 1 Nov 2022 11:26:16 -0700
From:   Guenter Roeck <linux@...ck-us.net>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Russell King <rmk+kernel@...linux.org.uk>,
        Masahiro Yamada <masahiroy@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Miguel Ojeda <ojeda@...nel.org>
Subject: Re: Linux 6.1-rc3

On Tue, Nov 01, 2022 at 06:57:41PM +0100, Arnd Bergmann wrote:
> On Tue, Nov 1, 2022, at 18:29, Linus Torvalds wrote:
> 
> > IOW, I expect it is - once again - some random linker-generated stub
> > that ends up causing problems, where the re-link stage ends up being
> > unstable because of some subtle alignment issue or other. I think
> > zero-sized symbols have often been involved.
> 
> Linker-generated symbols are usually the cause, but those tend to
> be fixed with the extra pass, and Guenter said that doing an extra
> pass does not avoid the issue here.
> 
> I have not tried to understand what the 73bbb94466fd patch actually does,
> but as the description explains that it uses either 1-byte or
> 2-byte encodings for some symbols, I suspect this is related to
> the new problem here, possibly it gets into an oscillating state
> where making the symbol table shorter causes a symbol to use the
> longer representation in the next round, which in turn makes the
> table longer again.
> 
> What I've done in the past to debug this was to change
> scripts/link-vmlinux.sh to use a larger number of steps,
> mainly to see if it eventually converges, grows indefinitely
> or oscillates. After that I would compare the temporary files
> from the last two different steps to see which symbols are
> actually different. Unfortunately, there is no built-in
> debugging mode in kallsyms, so this is a rather manual process.
> 
I have been doing the same, but so far I never encountered the oscillating
situation. In those all I can find is that some symbol addresses keep
changing, but I have not been able to track down the cause. The possible
explanation above makes sense to me, but do you have an idea how I could
track down what actually happens ?

Thanks,
Guenter