linux-kernel - Re: [PATCH 5/5] x86_64 EFI support -v3: EFI document

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-next>] [day] [month] [year] [list]

Date:	Thu, 9 Aug 2007 11:47:14 +0200 (CEST)
From:	Etienne Lorrain <etienne_lorrain@...oo.fr>
To:	linux-kernel@...r.kernel.org
Cc:	ebiederm@...ssion.com, ak@...e.de
Subject: Re: [PATCH 5/5] x86_64 EFI support -v3: EFI document

Eric W Biederman wrote:
> >> This is the classic skip the 16bit code and enter the kernel
> >> in 32bit mode filling in the fields that the 16bit mode code would
> >> have filled in the same way approach.
> > ......
> >
> > For in tree code it can be just updated. But weirdo-EFI-boot loader
> > cannot.
>
> So far the logic has been.
>
> Inspect bzImage.  And get boot protocol version.
> If field we need for returning data is not supported do not give
> data.  Or something like that.  Usually the fields always exist
> and you can just fill them in and we only append to the boot
> protocol structure.
>
> In practice this has been working for the last 7 years or so,
> for EFI, and LinuxBIOS, and kexec, and Gujin and I don't remember what
> else.

 Note that Gujin has a simple problem by using that 32 bits entry point:
there is no way to detect if the bzImage is compiled for 32 bits or 64 bits,
and Linux-real-mode calls a BIOS service for 64 bits only (to tell the BIOS you
are going to 64 bits - interrupt not really documented).
 Gujin can now be set to start at the 16 bits entry point, and load ELF32/ELF64
where you now the target word size, but the 32 bits entry point will "forget"
to call that service if the Linux kernel is 64 bits.
 The 32 bits entry point can still be used (-p parameter of tiny.exe) because
there seems to be a problem using the 16 bits entry point under DOS, at least
the old assembly version of the code - no more details known.

 Etienne.

      _____________________________________________________________________________ 
Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail 
-
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/