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]

Message-ID: <4F90527B.7020005@zytor.com>
Date:	Thu, 19 Apr 2012 10:59:23 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Borislav Petkov <bp@...64.org>
CC:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 3/3] x86, extable: Handle early exceptions

On 04/19/2012 10:38 AM, Borislav Petkov wrote:
> 
> Yeah, simplicity is the key here. I don't think we're getting that many
> early boot exceptions due to rdmsr or whatever to warrant adding a bunch
> of code.
> 
> OTOH, if we can share early and normal exception handling lookup code, then a
> perfect hash would make sense as those exceptions would pile up.
> 

Obviously we should use the hash after the main kernel is up, too.
Anything else would be silly.

I would argue that the O(1) hash makes things simpler as there is no
need to deal with collisions at all.  The one advantage with "plain"
hashes is that can be runtime modified, which would be of some interest
if we create one single hash table that includes modules.

*That* seems complex to me, though.

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