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  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:	Fri, 25 Jul 2014 11:29:06 -0700
From:	Linus Torvalds <>
To:	Steven Rostedt <>
Cc:	Alexei Starovoitov <>,
	Michel Dänzer <>,
	Jakub Jelinek <>,
	Linux Kernel Mailing List <>,
	Debian GCC Maintainers <>,
	Debian Kernel Team <>
Subject: Re: Random panic in load_balance() with 3.16-rc

On Fri, Jul 25, 2014 at 7:02 AM, Steven Rostedt <> 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?

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists