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-next>] [day] [month] [year] [list]

Message-ID: <52EBC65C.5020404@linux.vnet.ibm.com>
Date:	Fri, 31 Jan 2014 16:50:52 +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>,
	Borislav Petkov <borislav.petkov@....com>,
	"H. Peter Anvin" <hpa@...or.com>
Subject: Re: 3.13: BUG: unable to handle kernel paging request at 00000000b4343e88

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).

I tried to report this as a bug against GCC [1] but the report was
closed as invalid citing the following section from GCC documentation
for -fcall-saved-*:

  It is an error to use this flag with the frame pointer or stack
  pointer. Use of this flag for other registers that have fixed
  pervasive roles in the machine's execution model produces disastrous
  results.

Apparently %rdi is the first parameter register on x86_64 and therefore
qualifies as having a fixed pervasive role.

Digging deeper into the history of commit d61931d89b I found a
discussion [2] indicating that the use of -fcall-saved-rdi is not
strictly necessary with a dummy inline asm constraint being a potential
alternative. I've added Borislav Petkov and H. Peter Anvin who have been
involved in the discussion of this commit to CC:, hoping that they might
be able to provide a solution to this problem.

[1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60008
[2] http://lkml.org/lkml/2010/2/23/24

-- 
Peter Oberparleiter
Linux on System z Development - IBM Germany

--
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/