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

Date:	Fri, 25 Jul 2014 16:13: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 13:01:11 -0700
Linus Torvalds <torvalds@...ux-foundation.org> wrote:


> For example, gcc will not create a small stack frame with "sub
> $8,%rsp". No, what gcc does is to use a random "push" instruction.
> Fair enough, but that really makes things much harder to see. Here's
> an example:
> 
>   ffffffff813143a3 <dock_notify>:
>   ffffffff813143a3:       55                      push   %rbp
>   ffffffff813143a4:       48 89 e5                mov    %rsp,%rbp
>   ffffffff813143a7:       41 57                   push   %r15
>   ffffffff813143a9:       41 56                   push   %r14
>   ffffffff813143ab:       49 89 fe                mov    %rdi,%r14
>   ffffffff813143ae:       41 55                   push   %r13
>   ffffffff813143b0:       41 89 f5                mov    %esi,%r13d
>   ffffffff813143b3:       41 54                   push   %r12
>   ffffffff813143b5:       53                      push   %rbx
>   ffffffff813143b6:       51                      push   %rcx
>   ...
>   ffffffff81314501:       48 8b 7e 08             mov    0x8(%rsi),%rdi
>   ffffffff81314505:       48 89 75 d0             mov    %rsi,-0x30(%rbp)
>   ffffffff81314509:       e8 5f d1 ff ff          callq
> ffffffff8131166d <acpi_bus_scan>
>   ffffffff8131450e:       85 c0                   test   %eax,%eax
>   ...
>   ffffffff813145d6:       5a                      pop    %rdx
>   ffffffff813145d7:       5b                      pop    %rbx
>   ffffffff813145d8:       44 89 e0                mov    %r12d,%eax
>   ffffffff813145db:       41 5c                   pop    %r12
>   ffffffff813145dd:       41 5d                   pop    %r13
>   ffffffff813145df:       41 5e                   pop    %r14
>   ffffffff813145e1:       41 5f                   pop    %r15
>   ffffffff813145e3:       5d                      pop    %rbp
>   ffffffff813145e4:       c3                      retq
> 
> note the use (deep down in the function) of -0x30(%rbp), and note how
> it does "pop %rdx" twice to undo the "push %rcx". It was just to
> allocate space.

I don't see a pop %rdx twice. Sure you're not suffering from a little
dyslexia? ;-)  But I do get your point. The rdx is popped where the rcx
was, and both are useless, as rcx and rdx are volatile regs.


> 
> So you definitely have to track the actual stack pointer updates, not
> just the patterns of add/sub to %rsp.

With Perl that would be rather trivial. I'm more concerned with branch
logic. I'll see if I can include some simple branch logic too to
flatten paths. But I wont really know the depth of this until I start
hacking at it.

-- Steve



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