linux-kernel - Problems with commit 'kallsyms: add support for relative offsets in kallsyms address table' (in mmotm)

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: <56A431B5.8010505@roeck-us.net>
Date:	Sat, 23 Jan 2016 18:06:45 -0800
From:	Guenter Roeck <linux@...ck-us.net>
To:	Ard Biesheuvel <ard.biesheuvel@...aro.org>
Cc:	Heiko Carstens <heiko.carstens@...ibm.com>,
	Michael Ellerman <mpe@...erman.id.au>,
	Kees Cook <keescook@...omium.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Problems with commit 'kallsyms: add support for relative offsets in
 kallsyms address table' (in mmotm)

Hi,

I see runtime problems with the current mmotm branch. All qemu mips targets
(32 and 64 bit, big and little endian) are stuck in boot after this commit.

Bisect points to commit d13682e4d9d2 ("kallsyms: add support for relative offsets
in kallsyms address table". Disabling CONFIG_KALLSYMS_BASE_RELATIVE fixes the problem,
ie I can boot the image with qemu.

Bisect log is attached.

Playing with the problem, I found the following:

1) The problem is only seen with a toolchain using binutils 2.22, but not
    with a toolchain using binutils 2.25. The compiler configuration may be
    different for both toolchains.
2) Message "kallsyms failure: absolute symbol value 0xffffffff807afd14 out of range
    in relative mode" (twice) when using the toolchain with binutils 2.22.
    This does not cause the build to fail, though.
3) kallsyms_sym_address() parameter variable type is "int". In the calling code,
    the variable type used is "unsigned long". That has no impact on the problem,
    though.

Please let me know if there is anything I can do to help tracking down the problem.

Thanks,
Guenter

---
# bad: [437b7ef6d6484bb36afb2c75897e14bf03113dbd] pci: test for unexpectedly disabled bridges
# good: [afd2ff9b7e1b367172f18ba7f693dfb62bdcb2dc] Linux 4.4
git bisect start 'HEAD' 'v4.4'
# bad: [10078c1820d81131bc338c7c919feb2638a912ad] ocfs2: o2hb: add NEGOTIATE_APPROVE message
git bisect bad 10078c1820d81131bc338c7c919feb2638a912ad
# bad: [1b06048b37e888edb609e1509070ec0c6580eedd] kallsyms-add-support-for-relative-offsets-in-kallsyms-address-table-fix
git bisect bad 1b06048b37e888edb609e1509070ec0c6580eedd
# good: [ed312d94332968c86f53295795a3d122fd32cea2] arch/alpha/kernel/systbls.S: remove debug check
git bisect good ed312d94332968c86f53295795a3d122fd32cea2
# good: [1cbe7000217b0126821ecd8fba0ba5f9315a0560] thp: limit number of object to scan on deferred_split_scan()
git bisect good 1cbe7000217b0126821ecd8fba0ba5f9315a0560
# good: [474324b13e8184aa088c722b771f0f31ab773476] vmstat: remove BUG_ON from vmstat_update
git bisect good 474324b13e8184aa088c722b771f0f31ab773476
# good: [d94a9840c248207040d62ca0f380943db9423418] proc: fix missing reference of mm
git bisect good d94a9840c248207040d62ca0f380943db9423418
# bad: [d13682e4d9d2ad8220354b5e1a2bd6623e1f2e38] kallsyms: add support for relative offsets in kallsyms address table
git bisect bad d13682e4d9d2ad8220354b5e1a2bd6623e1f2e38
# first bad commit: [d13682e4d9d2ad8220354b5e1a2bd6623e1f2e38] kallsyms: add support for relative offsets in kallsyms address table