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: <86802c440708191646r1caab5d8yd82c55fd2c8262db@mail.gmail.com>
Date:	Sun, 19 Aug 2007 16:46:09 -0700
From:	"Yinghai Lu" <yhlu.kernel@...il.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	"Huang, Ying" <ying.huang@...el.com>,
	"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

On 8/19/07, Eric W. Biederman <ebiederm@...ssion.com> wrote:
> "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?
>

someone told me that EFI PEI will be 32 bit ( for mem etc
initialization), and after that will be 64 bit, so the Run time
service will be 64 bit only, and it will only support 64 bit OS with
EFI. and they have another mode to emulate the legacy BIOS to boot
32bit OS.

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