linux-kernel - Re: git pull request for tip/tracing/urgent

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:	Wed, 11 Feb 2009 02:28:56 +0100
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: git pull request for tip/tracing/urgent

On Tue, Feb 10, 2009 at 06:00:14PM -0500, Steven Rostedt wrote:
> 
> 
> On Tue, 10 Feb 2009, Frederic Weisbecker wrote:
> > > 
> > > diff --git a/arch/x86/kernel/ftrace.c b/arch/x86/kernel/ftrace.c
> > > index 1b43086..9d549e4 100644
> > > --- a/arch/x86/kernel/ftrace.c
> > > +++ b/arch/x86/kernel/ftrace.c
> > > @@ -491,13 +491,15 @@ void prepare_ftrace_return(unsigned long *parent, unsigned long self_addr)
> > >  		"1: " _ASM_MOV " (%[parent_old]), %[old]\n"
> > >  		"2: " _ASM_MOV " %[return_hooker], (%[parent_replaced])\n"
> > >  		"   movl $0, %[faulted]\n"
> > > +		"3:\n"
> > >  
> > >  		".section .fixup, \"ax\"\n"
> > > -		"3: movl $1, %[faulted]\n"
> > > +		"4: movl $1, %[faulted]\n"
> > > +		"   jmp 3b\n"
> > >  		".previous\n"
> > 
> > 
> > It thought after the fixup section, the code would continue to rest of the C code.
> > Where would it go without the jmp?
> 
> To the next item the linker placed into the .fixup section.  And that 
> would jump back to the location for that fixup. Basically, what you have 
> is this:
> 
> (just picking random and factitious registers)
> 
> .section .text
> [...]
> L1:	mov	%a, %b
> L2:	cmp	%x, $1
> <continue code>
> 
> 
> <Someplace else>
> 
> .section .text
> [...]
> L3:	mov	%c, %d
> L4:	cmp	%x, $22
> [...]
> 
> .section .fixup
> [...]
> L5:	mov	$1, %x
> 	jmp L2
> L6:	mov	$22, %x
> 	jmp L4
> [...]
> 
> 
> .section __ex_table
> [...]
> .long	L1, L5
> .long	L3, L6
> [...]
> 
> 
> So when we take an exception at label L1, the page fault code will look 
> to see if it is OK, by doing a binary search of the exception table.
> When it finds the L1, L5 pair, it will then set up a return to the L5 
> label.
> 
> When the fault returns to L5, it loads that reg %x with $1 and jumps back 
> to L2, where it can see that it took a fault.
> 
> Now lets look at what happens when we do not have that jump back to L2. 
> Instead of going back to the original code, it will load $22 into %x and 
> jmp back to the wrong area. God knows what will happen then, since the 
> stack pointer thinks it is from where the original fault occurred.


Heh, that's fairly logic. Don't ask me why, but I did not imagine each
part of .fixup unified in a separate contiguous section (but what else can it be?...).

Thanks for your explanations :-)

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