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]

Message-ID: <20090211090229.GG21105@elte.hu>
Date:	Wed, 11 Feb 2009 10:02:29 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Frederic Weisbecker <fweisbec@...il.com>
Cc:	Steven Rostedt <rostedt@...dmis.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Tejun Heo <tj@...nel.org>, "H. Peter Anvin" <hpa@...or.com>
Subject: Re: git pull request for tip/tracing/urgent


* Frederic Weisbecker <fweisbec@...il.com> wrote:

> > > 
> > > 
> > > 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 :-)

This bit:

  	".section .fixup, \"ax\"\n"
 	"4: movl $1, %[faulted]\n"
 	"   jmp 3b\n"
 	".previous\n"

Can be thought of as an 'embedded' or 'nested' section - the '.previous'
directive jumps back to whatever section we were in before. This can be
nested multiple times too:

   .section A
   [...]
     .section B
     [...]
        .section C
        [...]
        .previous
     [...]
     .previous
   [...]
   .previous

For whatever reason the interaction of the assembler with the linker and
in particular linker scripts are one of the most undocumented areas of OSS.
Does anyone know any good reference to start with? 

Something that explains the principles, how it all works, what the various
section flags mean in practice, including details like dwarf2/CFI annotations.

I do not know about any coherent documentation in this area and as a result
many developers shy away from this area, frequently mess it up if they have to
touch it and generally treat it as voodoo.

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