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]

Date:	Tue, 21 Aug 2007 12:53:23 +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 20:54 -0700, H. Peter Anvin wrote:
> Huang, Ying wrote:
> > 
> > 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.
> > 
> 
> That's making some pretty serious assumptions on future boot loaders and
> environments.

I think this assumption is reasonable. The range of u32 is big enough
for a boot protocol. Do we need to convert that to u128, when 128-bit
machine emerges?

I think there is another possible scheme. An array with variable length
element instead of a linked list can be used too. The type of element is
as follow:

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

The next element is at (char *)&setup_data + len. The boot information
will be held in a block of memory. This makes initial memory mapping of
kernel more easily. And the memory location of boot information may need
to be kept in a limited range too.

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

If a old boot loader (not aware of magic number) is used to load the new
kernel image. The old boot loader will set the magic number to zero.
Does this mean that the new kernel image can not be booted by the old
boot loader.

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/