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, 7 Mar 2017 11:38:21 -0600
From:   Josh Poimboeuf <jpoimboe@...hat.com>
To:     Pavel Machek <pavel@....cz>
Cc:     kernel list <linux-kernel@...r.kernel.org>, mingo@...nel.org,
        luto@...nel.org, bp@...en8.de, brgerst@...il.com,
        dvlasenk@...hat.com, hpa@...or.com, torvalds@...ux-foundation.org,
        peterz@...radead.org, tglx@...utronix.de
Subject: Re: v4.10: kernel stack frame pointer .. has bad value (null)

On Mon, Mar 06, 2017 at 05:38:07PM +0100, Pavel Machek wrote:
> Sorry for the delay. This is on v4.11-rc1, but that should be similar.
> 
> pavel@duo:~$ gcc --version
> gcc (Debian 4.9.2-10) 4.9.2
> 
> And here's the disassemble:
> 
> c402d200 <start_secondary>:
> c402d200:       57                      push   %edi
> c402d201:       8d 7c 24 08             lea    0x8(%esp),%edi
> c402d205:       83 e4 f8                and    $0xfffffff8,%esp
> c402d208:       ff 77 fc                pushl  -0x4(%edi)
> c402d20b:       55                      push   %ebp
> c402d20c:       89 e5                   mov    %esp,%ebp
> c402d20e:       57                      push   %edi
> c402d20f:       56                      push   %esi
> c402d210:       83 ec 10                sub    $0x10,%esp

Thanks.  This confirms what I was thinking, the function prologue is
wack.  It's realigning the stack, but it's not the "normal" realign
pattern.  Instead it makes a fake frame header, which saves a duplicate
copy of the return address ("pushl -0x4(%edi)") in a place the unwinder
wasn't expecting.

I did some digging in gcc to figure out why this can happen.  gcc uses
something called a Dynamic Realign Argument Pointer (DRAP), which, when
enabled, makes a prologue like the above.  It's almost always enabled
for aligned stacks when -maccumulate-outgoing-args isn't set.

So I'm thinking we should have -maccumulate-outgoing-args always enabled
on x86_32 just like we already do on x86_64.

Can you verify the warning is fixed with the following patch?

-----

diff --git a/arch/x86/Makefile_32.cpu b/arch/x86/Makefile_32.cpu
index 6647ed4..53ec1e4 100644
--- a/arch/x86/Makefile_32.cpu
+++ b/arch/x86/Makefile_32.cpu
@@ -61,7 +61,7 @@ ifeq ($(CONFIG_JUMP_LABEL), y)
 ADD_ACCUMULATE_OUTGOING_ARGS := y
 endif
 
-cflags-$(ADD_ACCUMULATE_OUTGOING_ARGS) += $(call cc-option,-maccumulate-outgoing-args)
+cflags-y += $(call cc-option,-maccumulate-outgoing-args)
 
 # Bug fix for binutils: this option is required in order to keep
 # binutils from generating NOPL instructions against our will.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ