linux-kernel - Re: Random panic in load

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

Message-ID: <20140804231918.36bd06f4@gandalf.local.home>
Date:	Mon, 4 Aug 2014 23:19:18 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Alexei Starovoitov <ast@...nel.org>,
	Michel Dänzer <michel@...nzer.net>,
	Jakub Jelinek <jakub@...hat.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Debian GCC Maintainers <debian-gcc@...ts.debian.org>,
	Debian Kernel Team <debian-kernel@...ts.debian.org>
Subject: Re: Random panic in load_balance() with 3.16-rc

On Fri, 25 Jul 2014 11:29:06 -0700
Linus Torvalds <torvalds@...ux-foundation.org> wrote:

> On Fri, Jul 25, 2014 at 7:02 AM, Steven Rostedt <rostedt@...dmis.org> wrote:
> >
> > But wouldn't it be rather trivial to run a static analyzer on the final
> > vmlinux to make sure there are no red zones? I mean, you would only need
> > to read each function and check to make sure that the offset of rbp is
> > within the change of rsp, wouldn't you?
> >
> > Almost seems like an objdump -rd into a perl script could do this.
> 
> I'm sure it's possible, but it sounds potentially complicated. It's
> not like the function prologue is fixed, and gcc will create code
> (including conditional branches etc) before the whole frame setup if
> there are simple things that can be done purely with the
> callee-clobbered registers etc.
> 
> Some simple pattern to make sure that the "sub $frame-size,%rsp" comes
> before any accesses to (%rbp) (when frame pointers are enabled)
> *might* work, but it might also end up missing things.
> 
> You want to try?
> 

I tried :-)

Seems to stay clean with my x86_64 vmlinux build. I compiled the fair.s
file and tested it and it got this:

$ objump -dr fair.o | ./check-vmlinux.pl
ERROR: <load_balance>: depth=-40 offset=136 at 4210
    3572:	48 c7 85 78 ff ff ff 	movq   $0x0,-0x88(%rbp)
ERROR: <sched_group_set_shares>: depth=8 offset=48 at 5734
    4a79:	48 89 45 d0          	mov    %rax,-0x30(%rbp)
ERROR: <sched_group_set_shares>: depth=8 offset=48 at 5743
    4a9c:	48 8b 75 d0          	mov    -0x30(%rbp),%rsi

The sched_group_set_shares errors seem to be bogus as that is done
after %rbp has been popped. Looks to be code that was jumped to from
the main body. I could probably fix this by ignoring code after a pop
of %rbp. Or make it more complex and be a bit smarter about branches.

The script will read a file if passed by parameter, otherwise it reads
standard input.

e.g.

$ objump -dr fair.o | ./check-vmlinux.pl

or

$ objdump -dr fair.o > /tmp/fair.dump
$ ./check-vmlinux.pl /tmp/fair.dump

produce the same.

It's a little hacky, but I only spent a half hour at most on it.

-- Steve

Download attachment "check-vmlinux.pl" of type "application/x-perl" (1468 bytes)