- 11 Aug, 2014 1 commit
-
-
H. Peter Anvin authored
* Enforce CONFIG_RELOCATABLE for the x86 EFI boot stub, otherwise it's possible to overwrite random pieces of unallocated memory during kernel decompression, leading to machine resets. Resolved Conflicts: arch/x86/Kconfig Signed-off-by:H. Peter Anvin <hpa@linux.intel.com>
-
- 05 Aug, 2014 1 commit
-
-
Matt Fleming authored
Without CONFIG_RELOCATABLE the early boot code will decompress the kernel to LOAD_PHYSICAL_ADDR. While this may have been fine in the BIOS days, that isn't going to fly with UEFI since parts of the firmware code/data may be located at LOAD_PHYSICAL_ADDR. Straying outside of the bounds of the regions we've explicitly requested from the firmware will cause all sorts of trouble. Bruno reports that his machine resets while trying to decompress the kernel image. We already go to great pains to ensure the kernel is loaded into a suitably aligned buffer, it's just that the address isn't necessarily LOAD_PHYSICAL_ADDR, because we can't guarantee that address isn't in-use by the firmware. Explicitly enforce CONFIG_RELOCATABLE for the EFI boot stub, so that we can load the kernel at any address with the correct alignment. Reported-by:
Bruno Prémont <bonbons@linux-vserver.org> Tested-by:
Matt Fleming <matt.fleming@intel.com>
-
- 04 Aug, 2014 1 commit
-
-
Matt Fleming authored
Building a 32-bit kernel with CONFIG_X86_USE_3DNOW and CONFIG_EFI_STUB leads to the following build error, drivers/firmware/efi/libstub/lib.a(efi-stub-helper.o): In function `efi_relocate_kernel': efi-stub-helper.c:(.text+0xda5): undefined reference to `_mmx_memcpy' This is due to the fact that the EFI boot stub pulls in the 3DNow optimized versions of the memcpy() prototype from arch/x86/include/asm/string_32.h, even though the _mmx_memcpy() implementation isn't available in the EFI stub. For now, predicate CONFIG_EFI_STUB on !CONFIG_X86_USE_3DNOW. This is most definitely a temporary fix. A complete solution will involve selectively including kernel headers/symbols into the early-boot execution environment of the EFI boot stub, i.e. something analogous to the way that the _SETUP symbol is used. Previous attempts have been made to fix this kind of problem, though none seem to have ever been merged, http://lkml.kernel.org/r/20120329104822.GA17233@x1.osrc.amd.com Clearly, this problem has been around for a long time. Reported-by:
Ingo Molnar <mingo@kernel.org> Cc: Borislav Petkov <bp@suse.de> Signed-off-by:
-
- 18 Jul, 2014 21 commits
-
-
Ard Biesheuvel authored
If we cannot resolve the virtual address of the UEFI System Table, its physical offset must be missing from the virtual memory map, and there is really no point in proceeding with installing the virtual memory map and the runtime services dispatch table. So back out gracefully. Signed-off-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by:
Mark Salter <msalter@redhat.com> Acked-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
-
Daniel Kiper authored
Compiler complains in the following way when x86 32-bit kernel with Xen support is build: CC arch/x86/xen/enlighten.o arch/x86/xen/enlighten.c: In function ‘xen_start_kernel’: arch/x86/xen/enlighten.c:1726:3: warning: right shift count >= width of type [enabled by default] Such line contains following EFI initialization code: boot_params.efi_info.efi_systab_hi = (__u32)(__pa(efi_systab_xen) >> 32); There is no issue if x86 64-bit kernel is build. However, 32-bit case generate warning (even if that code will not be executed because Xen does not work on 32-bit EFI platforms) due to __pa() returning unsigned long type which has 32-bits width. So move whole EFI initialization stuff to separate function and build it conditionally to avoid above mentioned warning on x86 32-bit architecture. Signed-off-by:
Daniel Kiper <daniel.kiper@oracle.com> Reviewed-by:
Konrad Rzeszutek Wilk <Konrad.wilk@oracle.com> Signed-off-by:
-
Daniel Kiper authored
Add inline keyword to silence the following compiler warnings if xen_efi_probe() is not used: CC arch/x86/xen/setup.o In file included from arch/x86/xen/xen-ops.h:7:0, from arch/x86/xen/setup.c:31: include/xen/xen-ops.h:43:35: warning: ‘xen_efi_probe’ defined but not used [-Wunused-function] Signed-off-by: -
Michael Brown authored
The EFI boot stub goes to great pains to relocate the kernel image to an appropriately aligned address, as indicated by the ->kernel_alignment field in the bzImage header. However, for the PE stub entry case, we can request that the EFI PE/COFF loader do the work for us. Fix by exposing the desired alignment via the SectionAlignment field in the PE/COFF headers. Despite its name, this field provides an overall alignment requirement for the loaded file. (Naturally, the FileAlignment field describes the alignment for individual sections.) There is no way in the PE/COFF headers to express the concept of min_alignment; we therefore do not expose the minimum (as opposed to preferred) alignment. Signed-off-by:
Michael Brown <mbrown@fensystems.co.uk> Signed-off-by:
-
Ulf Winkelvos authored
Hopefully this will enable us to better debug: https://bugzilla.kernel.org/show_bug.cgi?id=68761Signed-off-by:
Ulf Winkelvos <ulf@winkelvos.de> Signed-off-by:
-
Lee, Chun-Yi authored
The original patch is from Ben Hutchings's contribution to debian kernel. Got Ben's permission to remove the code of efi-pstore.c and send to linux-efi: https://github.com/BlankOn/linux-debian/blob/master/debian/patches/features/all/efi-autoload-efivars.patch efivars is generally useful to have on EFI systems, and in some cases it may be impossible to load it after a kernel upgrade in order to complete a boot loader update. At the same time we don't want to waste memory on non-EFI systems by making them built-in. Instead, give them module aliases as if they are platform drivers, and register a corresponding platform device whenever EFI runtime services are available. This should trigger udev to load them. Signed-off-by:
Lee, Chun-Yi <jlee@suse.com> Cc: Ben Hutchings <ben@decadent.org.uk> Tested-by:
-
Matt Fleming authored
The comment describing how struct efivars->lock is used hasn't been updated in sync with the code. Fix it. Reported-by:
-
Daniel Kiper authored
efi_set_rtc_mmss() is never used to set RTC due to bugs found on many EFI platforms. It is set directly by mach_set_rtc_mmss(). Hence, remove unused efi_set_rtc_mmss() function. Signed-off-by:
-
Daniel Kiper authored
We've got constants, so let's use them instead of hard-coded values. Signed-off-by:
-
Daniel Kiper authored
This patch enables EFI usage under Xen dom0. Standard EFI Linux Kernel infrastructure cannot be used because it requires direct access to EFI data and code. However, in dom0 case it is not possible because above mentioned EFI stuff is fully owned and controlled by Xen hypervisor. In this case all calls from dom0 to EFI must be requested via special hypercall which in turn executes relevant EFI code in behalf of dom0. When dom0 kernel boots it checks for EFI availability on a machine. If it is detected then artificial EFI system table is filled. Native EFI callas are replaced by functions which mimics them by calling relevant hypercall. Later pointer to EFI system table is passed to standard EFI machinery and it continues EFI subsystem initialization taking into account that there is no direct access to EFI boot services, runtime, tables, structures, etc. After that system runs as usual. This patch is based on Jan Beulich and Tang Liang work. Signed-off-by:
Jan Beulich <jbeulich@suse.com> Signed-off-by:
Tang Liang <liang.tang@oracle.com> Signed-off-by:
David Vrabel <david.vrabel@citrix.com> Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com Signed-off-by:
-
Daniel Kiper authored
Define constants and structures which are needed to properly execute EFI related hypercall in Xen dom0. This patch is based on Jan Beulich and Tang Liang work. Signed-off-by:
Stefano Stabellini <stefano.stabellini@eu.citrix.com> Signed-off-by:
-
Daniel Kiper authored
Remove redundant set_bit(EFI_MEMMAP, &efi.flags) call. It is executed earlier in efi_memmap_init(). Signed-off-by:
-
Daniel Kiper authored
Remove redundant set_bit(EFI_SYSTEM_TABLES, &efi.flags) call. It is executed earlier in efi_systab_init(). Signed-off-by:
-
Daniel Kiper authored
Introduce EFI_PARAVIRT flag. If it is set then kernel runs on EFI platform but it has not direct control on EFI stuff like EFI runtime, tables, structures, etc. If not this means that Linux Kernel has direct access to EFI infrastructure and everything runs as usual. This functionality is used in Xen dom0 because hypervisor has full control on EFI stuff and all calls from dom0 to EFI must be requested via special hypercall which in turn executes relevant EFI code in behalf of dom0. Signed-off-by:
-
Daniel Kiper authored
Do not access EFI memory map if it is not available. At least Xen dom0 EFI implementation does not have an access to it. Signed-off-by:
-
Daniel Kiper authored
Use early_mem*() instead of early_io*() because all mapped EFI regions are memory (usually RAM but they could also be ROM, EPROM, EEPROM, flash, etc.) not I/O regions. Additionally, I/O family calls do not work correctly under Xen in our case. early_ioremap() skips the PFN to MFN conversion when building the PTE. Using it for memory will attempt to map the wrong machine frame. However, all artificial EFI structures created under Xen live in dom0 memory and should be mapped/unmapped using early_mem*() family calls which map domain memory. Signed-off-by:
-
Daniel Kiper authored
This is odd to use early_iounmap() function do tear down mapping created by early_memremap() function, even if it works right now, because they belong to different set of functions. The former is I/O related function and the later is memory related. So, create early_memunmap() macro which in real is early_iounmap(). This thing will help to not confuse code readers longer by mixing functions from different classes. EFI patches following this patch uses that functionality. Signed-off-by:
-
Matt Fleming authored
It appears that the BayTrail-T class of hardware requires EFI in order to powerdown and reboot and no other reliable method exists. This quirk is generally applicable to all hardware that has the ACPI Hardware Reduced bit set, since usually ACPI would be the preferred method. Cc: Len Brown <len.brown@intel.com> Cc: Mark Salter <msalter@redhat.com> Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com> Signed-off-by: -
Matt Fleming authored
Not only can EfiResetSystem() be used to reboot, it can also be used to power down machines. By and large, this functionality doesn't work very well across the range of EFI machines in the wild, so it should definitely only be used as a last resort. In an ideal world, this wouldn't be needed at all. Unfortunately, we're starting to see machines where EFI is the *only* reliable way to power down, and nothing else, not PCI, not ACPI, works. efi_poweroff_required() should be implemented on a per-architecture basis, since exactly when we should be using EFI runtime services is a platform-specific decision. There's no analogue for reboot because each architecture handles reboot very differently - the x86 code in particular is pretty complex. Patches to enable this for specific classes of hardware will be submitted separately. Tested-by:
-
Matt Fleming authored
Implement efi_reboot(), which is really just a wrapper around the EfiResetSystem() EFI runtime service, but it does at least allow us to funnel all callers through a single location. It also simplifies the callsites since users no longer need to check to see whether EFI_RUNTIME_SERVICES are enabled. Cc: Tony Luck <tony.luck@intel.com> Tested-by:
-
Ard Biesheuvel authored
This patch changes both x86 and arm64 efistub implementations from #including shared .c files under drivers/firmware/efi to building shared code as a static library. The x86 code uses a stub built into the boot executable which uncompresses the kernel at boot time. In this case, the library is linked into the decompressor. In the arm64 case, the stub is part of the kernel proper so the library is linked into the kernel proper as well. Signed-off-by:
-
- 10 Jul, 2014 2 commits
-
-
Michael Brown authored
The PE/COFF headers currently describe only the initialised-data portions of the image, and result in no space being allocated for the uninitialised-data portions. Consequently, the EFI boot stub will end up overwriting unexpected areas of memory, with unpredictable results. Fix by including a .bss section in the PE/COFF headers (functionally equivalent to the init_size field in the bzImage header). Signed-off-by:
-
Catalin Marinas authored
Currently, fdt_find_uefi_params() reports an error if no EFI parameters are found in the DT. This is however a valid case for non-UEFI kernel booting. This patch checks changes the error reporting to a pr_info("UEFI not found") when no EFI parameters are found in the DT. Signed-off-by:Leif Lindholm <leif.lindholm@linaro.org> Tested-by:
-
- 07 Jul, 2014 8 commits
-
-
Ard Biesheuvel authored
In order to move from the #include "../../../xxxxx.c" anti-pattern used by both the x86 and arm64 versions of the stub to a static library linked into either the kernel proper (arm64) or a separate boot executable (x86), there is some prepatory work required. This patch does the following: - move forward declarations of functions shared between the arch specific and the generic parts of the stub to include/linux/efi.h - move forward declarations of functions shared between various .c files of the generic stub code to a new local header file called "efistub.h" - add #includes to all .c files which were formerly relying on the #includor to include the correct header files - remove all static modifiers from functions which will need to be externally visible once we move to a static library Signed-off-by:
-
Ard Biesheuvel authored
This moves definitions depended upon both by code under arch/arm64/boot and under drivers/firmware/efi to <asm/efi.h>. This is in preparation of turning the stub code under drivers/firmware/efi into a static library. Signed-off-by:
-
Ard Biesheuvel authored
This moves definitions depended upon both by code under arch/x86/boot and under drivers/firmware/efi to <asm/efi.h>. This is in preparation of turning the stub code under drivers/firmware/efi into a static library. Signed-off-by:
-
Ard Biesheuvel authored
As EFI_ERROR is not a UEFI result code but a local invention only intended to allow get_dram_base() to signal failure, we should not use it elsewhere. Replace with EFI_LOAD_ERROR. Signed-off-by:
-
Ard Biesheuvel authored
According to the UEFI spec section 2.3.6.4, the use of FP/SIMD instructions is allowed, and should adhere to the AAPCS64 calling convention, which states that 'only the bottom 64 bits of each value stored in registers v8-v15 need to be preserved' (section 5.1.2). This applies equally to UEFI Runtime Services called by the kernel, so make sure the FP/SIMD register file is preserved in this case. We do this by enabling the wrappers for UEFI Runtime Services (CONFIG_EFI_RUNTIME_WRAPPERS) and inserting calls to kernel_neon_begin()and kernel_neon_end() into these wrappers. Signed-off-by:
-
Ard Biesheuvel authored
In order for other archs (such as arm64) to be able to reuse the virtual mode function call wrappers, move them to drivers/firmware/efi/runtime-wrappers.c. Signed-off-by:
-
Ard Biesheuvel authored
The shared efistub code for ARM and arm64 contains a local copy of linux_banner, allowing it to be referenced from separate executables such as the ARM decompressor. However, this introduces a dependency on generated header files, causing unnecessary rebuilds of the stub itself and, in case of arm64, vmlinux which contains it. On arm64, the copy is not actually needed since we can reference the original symbol directly, and as it turns out, there may be better ways to deal with this for ARM as well, so let's remove it from the shared code. If it still needs to be reintroduced for ARM later, it should live under arch/arm anyway and not in shared code. Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
-
Ard Biesheuvel authored
The shared efistub code for ARM and arm64 contains a local copy of linux_banner, allowing it to be referenced from separate executables such as the ARM decompressor. However, this introduces a dependency on generated header files, causing unnecessary rebuilds of the stub itself and, in case of arm64, vmlinux which contains it. On arm64, the copy is not actually needed since we can reference the original symbol directly, and as it turns out, there may be better ways to deal with this for ARM as well, so let's remove it from the shared code. If it still needs to be reintroduced for ARM later, it should live under arch/arm anyway and not in shared code. Signed-off-by:
-
- 27 Jun, 2014 1 commit
-
-
Andrzej Zaborowski authored
In generic_id the long int timestamp is multiplied by 100000 and needs an explicit cast to u64. Without that the id in the resulting pstore filename is wrong and userspace may have problems parsing it, but more importantly files in pstore can never be deleted and may fill the EFI flash (brick device?). This happens because when generic pstore code wants to delete a file, it passes the id to the EFI backend which reinterpretes it and a wrong variable name is attempted to be deleted. There's no error message but after remounting pstore, deleted files would reappear. Signed-off-by:
Andrew Zaborowski <andrew.zaborowski@intel.com> Acked-by:
David Rientjes <rientjes@google.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
- 19 Jun, 2014 4 commits
-
-
Catalin Marinas authored
This patch fixes a few compiler warning in the efi code for unused variable, discarding const qualifier and wrong pointer type: drivers/firmware/efi/fdt.c|66 col 22| warning: unused variable ‘name’ [-Wunused-variable] drivers/firmware/efi/efi.c|368 col 3| warning: passing argument 3 of ‘of_get_flat_dt_prop’ from incompatible pointer type [enabled by default] drivers/firmware/efi/efi.c|368 col 8| warning: assignment discards ‘const’ qualifier from pointer target type [enabled by default] Signed-off-by:
-
Yinghai Lu authored
For boot efi kernel directly without bootloader. If the kernel support XLF_CAN_BE_LOADED_ABOVE_4G, we should not limit initrd under hdr->initrd_add_max. Signed-off-by:
Yinghai Lu <yinghai@kernel.org> Signed-off-by:
-
Matt Fleming authored
The kbuild reports the following sparse errors, >> arch/x86/platform/efi/quirks.c:242:23: sparse: incorrect type in >> argument 1 (different address spaces) arch/x86/platform/efi/quirks.c:242:23: expected void [noderef] <asn:2>*addr arch/x86/platform/efi/quirks.c:242:23: got void *[assigned] tablep >> arch/x86/platform/efi/quirks.c:245:23: sparse: incorrect type in >> argument 1 (different address spaces) arch/x86/platform/efi/quirks.c:245:23: expected void [noderef] <asn:2>*addr arch/x86/platform/efi/quirks.c:245:23: got struct efi_setup_data *[assigned] data Dave Young had made previous attempts to convert the early_iounmap() calls to early_memunmap() but ran into merge conflicts with commit 9e5c33d7 ("mm: create generic early_ioremap() support"). Now that we've got that commit in place we can switch to using early_memunmap() since we're already using early_memremap() in efi_reuse_config(). Cc: Dave Young <dyoung@redhat.com> Cc: Saurabh Tangri <saurabh.tangri@intel.com> Signed-off-by:
-
Saurabh Tangri authored
Currently, it's difficult to find all the workarounds that are applied when running on EFI, because they're littered throughout various code paths. This change moves all of them into a separate file with the hope that it will be come the single location for all our well documented quirks. Signed-off-by:
Saurabh Tangri <saurabh.tangri@intel.com> Signed-off-by:
-
- 16 Jun, 2014 1 commit
-
-
Linus Torvalds authored
-
