linux-kernel - Re: [PATCH] scripts: Make sortextable handle relocations.

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 20 Apr 2012 16:14:05 -0700
From:	David Daney <ddaney.cavm@...il.com>
To:	"H. Peter Anvin" <hpa@...or.com>
CC:	David Daney <ddaney.cavm@...il.com>,
	Ralf Baechle <ralf@...ux-mips.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>, x86@...nel.org,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Michal Marek <mmarek@...e.cz>, linux-kernel@...r.kernel.org,
	linux-mips@...ux-mips.org,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH] scripts: Make sortextable handle relocations.

On 04/20/2012 03:59 PM, H. Peter Anvin wrote:
> On 04/20/2012 03:41 PM, David Daney wrote:
>> From: David Daney<david.daney@...ium.com>
>>
>> If there are relocations on the __ex_table section, they must be fixed
>> up after the table is sorted.
>>
>> Also use the unaligned safe accessors from tools/{be,le}_byteshift.h
>>
>> Signed-off-by: David Daney<david.daney@...ium.com>
>> ---
>>
>> This should address HPA's concerns about the i386 relocations.  The
>> i386 kernel still boots after the sort, but I don't know how to test
>> the relocations, but they sure do look nice!  My MIPS64 kernels still
>> boot too, so that is also good.
>>
>
> Hi...
>
> This works for absolute relocations of the REL type, but not for
> relocations of the RELA type nor for non-absolute relocations (moving
> those changes the meaning.)

The program explicitly only handles MIPS and x86.

x86_64 and MIPS never have relocations, and x86_32 is always REL, so 
that is handled

Also x86_32 is only emitting R_386_32 and those are handled.

>
> I think Linus is right and the right thing to do is to switch to using
> relative entries in the exception table; I am currently testing a
> patchset to do exactly that (on x86).  It also has the benefit of making
> the table half the size on x86-64.  Then we can just zero out the
> .rel[a]__ex_table section and be done with it.

That's fine.

In any event we want to do build time sorting, this patch improves the 
original sortextable, so may be worthwhile as purely a cleanup.  I 
wanted to fix the relocation breakage, even if the eventual solution 
needs to be somewhat different.

>
> The trick, of course, is that sorting a relative table is slightly
> different than sorting an absolute table -- the way I'm doing it for the
> in-kernel sorter (still needed for modules) is to add the intra-section
> offset to each entry (both sides) before sorting, then doing a *signed*
> sort, then denormalize again.  Alpha does it differently, with custom
> compare and swap routines.
>
> 	-hpa
>

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