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: <m11wdzrwl7.fsf@ebiederm.dsl.xmission.com>
Date:	Sun, 19 Aug 2007 16:25:08 -0600
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	"Huang, Ying" <ying.huang@...el.com>
Cc:	"H. Peter Anvin" <hpa@...or.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Andi Kleen <ak@...e.de>,
	Chandramouli Narayanan <mouli@...ux.intel.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/3] x86_64 EFI runtime service support

"Huang, Ying" <ying.huang@...el.com> writes:

> On Thu, 2007-08-16 at 07:22 +0800, H. Peter Anvin wrote:
>> Andrew Morton wrote:
>> > On Mon, 13 Aug 2007 15:30:19 +0800
>> > "Huang, Ying" <ying.huang@...el.com> wrote:
>> >
>> >> Following sets of patches add EFI/UEFI (Unified Extensible Firmware
>> >> Interface) runtime services support to x86_64 architecture.
>> >
>> > OK, we have a major trainwreck when these patches meet Peter's
>> > get-newsetup.patch.
>> >
>> > I'm halfway into fixing it when I see this.  You have:
>> >
>> >  #define SYS_DESC_TABLE (*(struct sys_desc_table_struct*)(PARAM
>> +0xa0))
>> > +#define EFI_LOADER_SIG ((unsigned char *)(PARAM+0x1c0))
>> > +#define EFI_MEMDESC_SIZE (*((unsigned int *) (PARAM+0x1c4)))
>> > +#define EFI_MEMDESC_VERSION (*((unsigned int *) (PARAM+0x1c8)))
>> > +#define EFI_MEMMAP_SIZE (*((unsigned int *) (PARAM+0x1cc)))
>> > +#define EFI_MEMMAP (*((unsigned long *)(PARAM+0x1d0)))
>> > +#define EFI_SYSTAB (*((unsigned long *)(PARAM+0x1d8)))
>> >  #define MOUNT_ROOT_RDONLY (*(unsigned short *) (PARAM+0x1F2))
>> >
>> 
>> Please, no more of these kinds of macros.  We have already had
>> collisions.  Go ahead and redefine the efi_info structure if
>> necessary,
>
> according to the git-newsetup.patch.
>
> One question:
>
> The boot_params.efi_info.efi_systab is defined as u32. But it should be
> u64 on x86_64, because it comes from firmware and is not controlled by
> bootloader. But, changing it from u32 to u64 will break current i386 EFI
> support, should we change it and fix the i386 EFI bootloader?

Be very very very  careful how you talk about this.

I have seen machines in the wild a 64bit processor and a 32bit EFI.
So this is not a linux architecture issue, or a cpu architecture
issue.  This is an EFI architecture issue.

This is an issue of do you have a 32bit or a 64bit EFI implementation
on your machine.  Which is very different.

We should be able to boot a 32bit kernel with a 64bit EFI.
We should be able to boot a 64bit kernel with a 32bit EFI.

Maybe our response is to ignore the information from elilo so
we don't attempt EFI runtime calls but the boot information should
be unambiguous.

So we need to be able to look at the data and answer these questions.
- Is EFI present?
- Is EFI 32bit?
- Is EFI 64bit?

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