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: Windows password security audit tool. GUI, reports in PDF.

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

Message-Id: <1187660689.20920.27.camel@caritas-dev.intel.com>
Date:	Tue, 21 Aug 2007 09:44:49 +0800
From:	"Huang, Ying" <ying.huang@...el.com>
To:	"H. Peter Anvin" <hpa@...or.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

On Mon, 2007-08-20 at 10:12 -0700, H. Peter Anvin wrote:
> Huang, Ying wrote:
> >>
> >> 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[];
> >> };
> >>

I think the "next" field can be u32 instead of u64. Because the linked
list of struct setup_data is prepared by bootloader, which can control
the memory location.

To facilitate the kernel early mapping, I think the memory location of
"linked list" should be kept to a predefined range (in the real mode
memory area?).

> > So, we need not define a new boot protocol, just extend the standard
> > boot protocol. The version number and magic need not to be added to
> > "zero page". But, at the same time, the bootloader on EFI, LinuxBIOS and
> > kexec must be changed accordingly.
> > 
> 
> I think this is too radical of a change to be practical.  Instead, I
> propose the following:
> 
> - "struct boot_params" (the zeropage) is kept as a legacy interface.
> %esi will continue to point to it on entry to the 32-bit entrypoint
> (presumably that is %rsi on entry to a 64-bit entrypoint?)
> 
> - We add a magic number and a pointer chain to the zeropage.  The
> presence of the magic number indicates that:
> 
> 	- Any unused fields in the zeropage is zero;
> 	- The pointer chain is valid (unless zero);
> 	- The old "HD info" fields (and possibly the EDD fields)
> 	  can be recycled.

Previously, I think the "zero page" is not external formally, so we can
ignore the user. But it is used by some bootloaders. So your proposal
may be better, especially for these bootloaders.

I think something others need to be done:

- Increase the version number of standard boot protocol.
- Add the contents of zero page into standard boot protocol document as
a optional part for 32-bit entry (and 64-bit entry?).
- Make 32-bit (64-bit?) boot protocol formal in standard boot protocol
document.

> What a post-upgrade kernel should do upon encountering an old structure
> (sans magic) is to zero out any fields that wasn't present in the legacy
> structure definition, including the pointer chain, then it can use it as-is.

As for the magic number in zero page, do you think it should be used
only by 16-bit kernel setup code?

> We should avoid adding fields to the zero_page after that, unless
> necessary for backwards compatibility reasons.  In general, new data
> items should be added as pointer capabilities.

Yes.

> Compare this to the legacy PCI header vs. PCI capabilities.

Best Regards,
Huang Ying
-
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/