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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ