diff options
author | jljusten <jljusten@6f19259b-4bc3-4df7-8a09-765794883524> | 2013-01-14 03:10:57 +0000 |
---|---|---|
committer | jljusten <jljusten@6f19259b-4bc3-4df7-8a09-765794883524> | 2013-01-14 03:10:57 +0000 |
commit | 61a114ba46e18b2490f4b4abe457f506fe9a47fc (patch) | |
tree | c8535471e6df3e7067505a00f3a7f7673d14971c /CryptoPkg | |
parent | fda93fc4495ca0343d57f82b8df4583d3f877b8f (diff) | |
download | edk2-platforms-61a114ba46e18b2490f4b4abe457f506fe9a47fc.tar.xz |
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
Diffstat (limited to 'CryptoPkg')
0 files changed, 0 insertions, 0 deletions