linux-kernel - Re: 3.13: BUG: unable to handle kernel paging request at 00000000b4343e88

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: <52F26E21.8000101@linux.vnet.ibm.com>
Date:	Wed, 05 Feb 2014 18:00:17 +0100
From:	Peter Oberparleiter <oberpar@...ux.vnet.ibm.com>
To:	Meelis Roos <mroos@...ux.ee>
CC:	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Kernel list <linux-kernel@...r.kernel.org>,
	"H. Peter Anvin" <hpa@...or.com>
Subject: Re: 3.13: BUG: unable to handle kernel paging request at 00000000b4343e88

On 31.01.2014 16:50, Peter Oberparleiter wrote:
> On 29.01.2014 21:44, Meelis Roos wrote:
>>>> I do not get very far - it still crashes on startuo. PNG attached.
>>>
>>> I tried to reproduce this behavior a couple of times with no success.
>>> Could you post your kernel configuration? I've also modified the
>>> debugging patch to ensure that the gcov_info structure passed to
>>> gcov_init() is no longer accessed beyond displaying the first 64
>>> bytes. If you could apply this and send dmesg output, this might
>>> hopefully provide a clue as to why the kernel cannot handle these
>>> data structures correctly.
>>
>> This patch makes it boot. dmesg and config are below.
> 
> Using your config I was able to reproduce the crash and locate the
> cause. Commit d61931d89b, "x86: Add optimized popcnt variants" adds
> option -fcall-saved-rdi to the compile flags of lib/hweight.c when
> compiling for x86_64. Together with options --coverage and -O2, this
> results in a broken constructor being generated by GCC for this object
> file which in turn causes __gcov_init() to overwrite random memory
> locations (a mutex in your case).

Could you give this patch a try? It is a variation of the approach
proposed in the discussion mentioned earlier and fixes the problem
on my system.

--
diff -Naurp a/arch/x86/include/asm/arch_hweight.h b/arch/x86/include/asm/arch_hweight.h
--- a/arch/x86/include/asm/arch_hweight.h
+++ b/arch/x86/include/asm/arch_hweight.h
@@ -25,9 +25,18 @@ static inline unsigned int __arch_hweigh
 {
 	unsigned int res = 0;

+#ifdef CONFIG_X86_32
 	asm (ALTERNATIVE("call __sw_hweight32", POPCNT32, X86_FEATURE_POPCNT)
 		     : "="REG_OUT (res)
 		     : REG_IN (w));
+#else
+	/* Tell gcc that %rdi is clobbered as an input operand */
+	unsigned long dummy;
+
+	asm (ALTERNATIVE("call __sw_hweight32", POPCNT32, X86_FEATURE_POPCNT)
+		     : "="REG_OUT (res), "=D" (dummy)
+		     : REG_IN (w));
+#endif /* CONFIG_X86_32 */

 	return res;
 }
@@ -50,8 +59,11 @@ static inline unsigned long __arch_hweig
 	return  __arch_hweight32((u32)w) +
 		__arch_hweight32((u32)(w >> 32));
 #else
+	/* Tell gcc that %rdi is clobbered as an input operand */
+	unsigned long dummy;
+
 	asm (ALTERNATIVE("call __sw_hweight64", POPCNT64, X86_FEATURE_POPCNT)
-		     : "="REG_OUT (res)
+		     : "="REG_OUT (res), "=D" (dummy)
 		     : REG_IN (w));
 #endif /* CONFIG_X86_32 */

diff -Naurp a/arch/x86/Kconfig b/arch/x86/Kconfig
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -254,7 +254,7 @@ config X86_32_LAZY_GS
 config ARCH_HWEIGHT_CFLAGS
 	string
 	default "-fcall-saved-ecx -fcall-saved-edx" if X86_32
-	default "-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx -fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 -fcall-saved-r11" if X86_64
+	default "-fcall-saved-rsi -fcall-saved-rdx -fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 -fcall-saved-r11" if X86_64

 config ARCH_SUPPORTS_UPROBES
 	def_bool y

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/