linux-kernel - Re: [PATCH 0/3] x86_64 EFI runtime service support

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]

Message-ID: <46C5C8C4.4060407@zytor.com>
Date:	Fri, 17 Aug 2007 09:11:48 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	"Huang, Ying" <ying.huang@...el.com>
CC:	Andi Kleen <ak@...e.de>, Andrew Morton <akpm@...ux-foundation.org>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Chandramouli Narayanan <mouli@...ux.intel.com>,
	linux-kernel@...r.kernel.org, Aaron Durbin <adurbin@...gle.com>
Subject: Re: [PATCH 0/3] x86_64 EFI runtime service support

Huang, Ying wrote:
>>
>> Has the zero page documentation and version numbering project
>> made any progress? I think we cannot merge this without at least
>> the version number
> 

More than that.  You need to be able to boot a 32-bit kernel on a 64-bit
system, so anything that breaks that is a nonstarter.  Of course, if EFI
itself inherently breaks that, then, well, that's just another reason to
avoid EFI like the plague, but I can't think that even EFI is that broken.

> OK, I will work on the zero page documentation and version numbering
> project.

There already is documentation (Documentation/i386/zero-page.txt); as
far as version numbering, that means sticking in a field with a number,
and adding a magic number (since there isn't anything that guarantees
that fields are otherwise zero.)

Anything that conforms to the updated standard should guarantee
undefined fields are zero.

However, we also have an immediate need to define how to grow past 4K,
and if we're going to have a major revision in mechanism I would like to
see that happen now.

I propose that, in addition to the aforementioned version number and
magic fields, we add a pointer, which should be the last pointer added
that doesn't point into I/O space or reserved memory (i.e. memory that
is off limit anyway for the operating system.)

This pointer should point to a linked list of suggested form:

struct setup_data {
	u64 next;
	u32 type;
	u32 len;
	u8 data[];
};

This can thus encapsulate large objects as necessary, and the early
kernel entry can linearize them if it needs to move them out of the way.
 Better yet, this information can be made available to sysfs for
debuggability, and/or use by kexec.

I haven't heard anything from the kexec people on this, and they are the
main users of the PM entrypoint as far as I can tell.

Also, is there a maintainer for 32-bit EFI?

	-hpa

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