]> git.proxmox.com Git - mirror_edk2.git/commit
OvmfPkg: LoadLinuxLib: Fix kernel entry for 64-bit OVMF
authorjljusten <jljusten@6f19259b-4bc3-4df7-8a09-765794883524>
Mon, 14 Jan 2013 03:10:57 +0000 (03:10 +0000)
committerjljusten <jljusten@6f19259b-4bc3-4df7-8a09-765794883524>
Mon, 14 Jan 2013 03:10:57 +0000 (03:10 +0000)
commit61a114ba46e18b2490f4b4abe457f506fe9a47fc
treec8535471e6df3e7067505a00f3a7f7673d14971c
parentfda93fc4495ca0343d57f82b8df4583d3f877b8f
OvmfPkg: LoadLinuxLib: Fix kernel entry for 64-bit OVMF

We currently just jump to offset 0x200 in the kernel image, in 64-bit
mode. This is completely broken. If it's a 32-bit kernel, we'll be
jumping into the compressed data payload.

If it's a 64-bit kernel, it'll work... but the 0x200 offset is
explicitly marked as 'may change in the future', has already changed
from 0x100 to 0x200 in the past with no fanfare, and bootloaders are
instructed that they should look at the ELF header to find the offset.
So although it does actually work today, it's still broken in the
"someone needs to whipped for doing it this way" sense of the word.

In fact, the same bug exists in other bootloaders so the 0x200 offset
probably *is* now set in stone. But still it's only valid to use it if
we *know* it's a 64-bit kernel. And we don't. There *is* no ELF header
that we can look at when we're booting a bzImage, and we can't rely on
it having a PE/COFF header either.

The 32-bit entry point is always guaranteed to work, and we need to
support it anyway. So let's just *always* use it, in 32-bit mode, and
then we don't have to make up some horrible heuristics for detecting
32-bit vs. 64-bit kernels.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14045 6f19259b-4bc3-4df7-8a09-765794883524
OvmfPkg/Library/LoadLinuxLib/X64/JumpToKernel.S
OvmfPkg/Library/LoadLinuxLib/X64/JumpToKernel.asm