aboutsummaryrefslogtreecommitdiffstats
path: root/arch/x86/kernel/setup.c
diff options
context:
space:
mode:
authorMatthew Garrett <mjg@redhat.com>2011-05-25 09:53:13 -0400
committerH. Peter Anvin <hpa@linux.intel.com>2011-05-25 20:03:53 -0400
commit916f676f8dc016103f983c7ec54c18ecdbb6e349 (patch)
treee7ad675e225c0314191d4fe3e4dc23920bfcad5f /arch/x86/kernel/setup.c
parent8b27f2ff7a24f0735c96055e676872f05398d99b (diff)
x86, efi: Retain boot service code until after switching to virtual mode
UEFI stands for "Unified Extensible Firmware Interface", where "Firmware" is an ancient African word meaning "Why do something right when you can do it so wrong that children will weep and brave adults will cower before you", and "UEI" is Celtic for "We missed DOS so we burned it into your ROMs". The UEFI specification provides for runtime services (ie, another way for the operating system to be forced to depend on the firmware) and we rely on these for certain trivial tasks such as setting up the bootloader. But some hardware fails to work if we attempt to use these runtime services from physical mode, and so we have to switch into virtual mode. So far so dreadful. The specification makes it clear that the operating system is free to do whatever it wants with boot services code after ExitBootServices() has been called. SetVirtualAddressMap() can't be called until ExitBootServices() has been. So, obviously, a whole bunch of EFI implementations call into boot services code when we do that. Since we've been charmingly naive and trusted that the specification may be somehow relevant to the real world, we've already stuffed a picture of a penguin or something in that address space. And just to make things more entertaining, we've also marked it non-executable. This patch allocates the boot services regions during EFI init and makes sure that they're executable. Then, after SetVirtualAddressMap(), it discards them and everyone lives happily ever after. Except for the ones who have to work on EFI, who live sad lives haunted by the knowledge that someone's eventually going to write yet another firmware specification. [ hpa: adding this to urgent with a stable tag since it fixes currently-broken hardware. However, I do not know what the dependencies are and so I do not know which -stable versions this may be a candidate for. ] Signed-off-by: Matthew Garrett <mjg@redhat.com> Link: http://lkml.kernel.org/r/1306331593-28715-1-git-send-email-mjg@redhat.com Signed-off-by: H. Peter Anvin <hpa@linux.intel.com> Cc: Tony Luck <tony.luck@intel.com> Cc: <stable@kernel.org>
Diffstat (limited to 'arch/x86/kernel/setup.c')
-rw-r--r--arch/x86/kernel/setup.c7
1 files changed, 7 insertions, 0 deletions
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 605e5ae19c7..b9ca498f560 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -910,6 +910,13 @@ void __init setup_arch(char **cmdline_p)
910 memblock.current_limit = get_max_mapped(); 910 memblock.current_limit = get_max_mapped();
911 memblock_x86_fill(); 911 memblock_x86_fill();
912 912
913 /*
914 * The EFI specification says that boot service code won't be called
915 * after ExitBootServices(). This is, in fact, a lie.
916 */
917 if (efi_enabled)
918 efi_reserve_boot_services();
919
913 /* preallocate 4k for mptable mpc */ 920 /* preallocate 4k for mptable mpc */
914 early_reserve_e820_mpc_new(); 921 early_reserve_e820_mpc_new();
915 922