linux-kernel - Re: tracing ring_buffer

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]

Message-ID: <1337909963.13348.232.camel@gandalf.stny.rr.com>
Date:	Thu, 24 May 2012 21:39:23 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	"H. Peter Anvin" <hpa@...ux.intel.com>
Cc:	Dave Jones <davej@...hat.com>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Ingo Molnar <mingo@...hat.com>, Andi Kleen <ak@...ux.intel.com>
Subject: Re: tracing ring_buffer_resize oops.

On Thu, 2012-05-24 at 16:53 -0700, H. Peter Anvin wrote:

> Much more fundamentally, RIP should never leave the range [-2G, 0).
> What is happening here is almost certainly that we jump through
> something which isn't a function pointer.
> 
> The other thing worth noting is that the code segment is not the
> standard Linux code segment, not even close; it *also* doesn't look like
> the typical Xen code segment.  This makes be believe that we did an IRET
> with the stack pointer set to something other than a valid interrupt
> stack frame.

I was thinking the same. But not from an NMI. Seems it may be a
breakpoint IRET that is the issue. Could also be a nesting issue with
the stack, as breakpoints have a single stack as well.

I may modify the code a little to see if I can trigger it on a normal
config. Right now, I can only trigger it with an allmodconfig. That may
also be the issue. It may have added some debugging that causes
something to be traced (and breakpoint added) that isn't normally
traced.


>   Specifically, note that the value of R12 is the same
> value; R12 is a preserved register and may have been pushed onto the
> stack by something that wants to save it.

I don't see R12 as the same value:

RIP: <ffff88014630a000>
GS: ffff880148000000
R12: ffff880145cc0000

Close but not quite. Even R13 and R15 are close:

R13: ffff880148008eb8
R15: ffff88014780cb40

But this probably does show that the stack is screwed up and did a bad
iret.

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