linux-kernel - Re: [PATCH 3/3] x86, extable: Handle early exceptions

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:	Thu, 19 Apr 2012 10:54:12 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Borislav Petkov <bp@...64.org>
CC:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	David Daney <david.daney@...ium.com>
Subject: Re: [PATCH 3/3] x86, extable: Handle early exceptions

On 04/19/2012 10:02 AM, H. Peter Anvin wrote:
> On 04/19/2012 02:26 AM, Borislav Petkov wrote:
>>
>> Also, move the sorting of the main exception table earlier in the boot
>> process now that we handle exceptions in the early IDT handler too.
>>
> 
> I would much rather use David Daney's patchset to sort the exception
> table at compile time:
> 
> 	https://lkml.org/lkml/2011/11/18/427
> 
> ... and I would be *even happier* with an O(1) hash (which pretty much
> *have* to be constructed at compile time.)
> 

The sorting is easier infrastructure-wise, since it can be done
in-place.  The O(1) hash needs additional space for the hash table
itself (the actual table can still be stashed where the compiler
generates it.)

The hash table generator I have posted at:

http://www.zytor.com/~hpa/phash/

Generally needs ~3.2 bytes per hash table entry, rounded up to a power
of two.  The rounding up is for performance.  The easiest way to do this
is probably to let the linker create a zero-filled section of the proper
size (since the linker knows the final size of the __ex_table section,
and the linker script can do at least a modicum of arithmetic) and then
use a tool to patch in the hash table auxilliary data.

	-hpa

P.S. Another modification which was talked about in the past and there
even were patches for was to make the exception table entries relative
to the start of the kernel, so we don't need two relocations per entry
for x86-32 and twice the amount of data that we can actually use for
x86-64.  As I recall we tried those patches and there was some bug that
never got resolved.

This is obviously a precondition for doing the O(1) hash, since the O(1)
hash can't be relocated once generated.
--
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/