linux-kernel - Re: [PATCH 5/5] x86_64 EFI support -v3: EFI document

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, 09 Aug 2007 09:29:05 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	huang ying <huang.ying.caritas@...il.com>
CC:	Andi Kleen <ak@...e.de>, linux-kernel@...r.kernel.org,
	ebiederm@...ssion.com
Subject: Re: [PATCH 5/5] x86_64 EFI support -v3: EFI document

huang ying wrote:
> 
> I think at least the following should be done to make it a external
> boot protocol.
> 
> 1. A version number field should be added.
> 2. The pointers (especially these come from firmware) should be 64bit
> to make the entry point can be used for both 32bit and 64bit platform.
> 3. More complete and formal document.
> 
> Can you kindly tell me what's more should be done?
> 

I have been looking at this recently, and also found that we already
have to make unacceptable compromises in order to fit into 4K, which is
set completely arbitrary (once upon a time, it was recycled as the
zeropage, but that is ancient history.)

Part of a formalizing the 32-bit/64-bit entrypoint involves a clean way
to extend this data set.

I mentioned in private email to a few people that I think a linked list
of tagged data items (similar to the way PCI capabilities work) would
probably make sense; we want a piece of code to know the structure
without needing to know the contents, in order to rescue data.

It's worth realizing that this is inherently never going to be as stable
as the real-mode entrypoint, and there is always going to be more
catch-up, simply because it's a broader interface.  What is blatantly
clear, however, is that the current structure is utterly ad hoc and has
been totally prematurely adopted as some sort of standard interface.
Since I've spent time formalizing the structure over the last few months
I've been rather horrified; it is truly as bad as you could get.

So, anyway, this has popped up on my radar already; it needs to happen
anyway so let's get the discussion started.

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