Sounds exciting, but I don’t know where to get eficheck. If someone knows, please leave a Comment to this post. Thanks!
Lukas Wunner submitted a 6-part patch to the Linux-(EFI,Kernel) lists with additional Apple EFI firmware support.
Apple device properties
Apple EFI drivers supply device properties which are needed to support Macs optimally. This series extends the efistub to retrieve the device properties before ExitBootServices is called (patch [1/6]). They are assigned to devices in an fs_initcall (patch [5/6]). As a first use case, the Thunderbolt driver is amended to take advantage of the Device ROM supplied by EFI (patch [6/6]). A by-product is a parser for EFI Device Paths which finds the struct device corresponding to a given path. This is needed to assign properties to their devices (patch [3/6]). […]
OSX Reverser has a new blog post on Apple EFI firmware passwords:
[…] This is when I had an idea! How about creating an EFI emulator and debugger using the Unicorn Engine framework? I had a feeling this wouldn’t be extremely hard and time consuming because the EFI environment is self contained – for example no linkers and syscalls to emulate. I also knew that this binary was more or less isolated, only using a few Boot and RunTime services and very few external protocols. Since the total number of Boot and RunTime services are very small this meant that there wasn’t a lot of code to be emulated. And with a couple of days work the EFI DXE Emulator was born. To my surprise I was finally able to run and debug an EFI binary in userland, speeding the reverse engineering process up immensely and quickly providing insight to previously tricky code. […]
Looking forward to an URL to this EFISwissKnife IDA plugin, and ESPECIALLY this new Unicorn-based EFI emulator! I can’t find an URL yet, though. 😦
OpenBSD 5.9 has been released. There are a few firmware-related improvements in this release, such as:
* New efifb(4) driver for EFI frame buffer.
* amd64 can now boot from 32 bit and 64 bit EFI.
* Initial support for hardware reduced ACPI added to acpi(4).
* New asmc(4) driver for the Apple System Management Controller.
* New dwiic(4) driver for the Synopsys DesignWare I2C controller.
* Support for ACPI configured SD host controllers has been added to sdhc(4).
* The sdmmc(4) driver now supports sector mode for eMMC devices, such as those found on some BeagleBone Black boards.
* The ipmi(4) driver now supports OpenIPMI compatible character device.
For the next Linux kernel, there are some new UEFI improvements to look forward to. Excerpting email from Ingo Molnar:
The main changes are:
– Use separate EFI page tables when executing EFI firmware code. This isolates the EFI context from the rest of the kernel, which has security and general robustness advantages. (Matt Fleming)
– Run regular UEFI firmware with interrupts enabled. This is already the status quo under other OSs. (Ard Biesheuvel)
– Various x86 EFI enhancements, such as the use of non-executable attributes for EFI memory mappings. (Sai Praneeth Prakhya)
– Various arm64 UEFI enhancements. (Ard Biesheuvel)
Alexander Graf of SuSE has been adding EFI support to U-Boot. He also just added a new boot loader command, ‘bootefi’, as well:
[PATCH v6 19/30] efi_loader: Add “bootefi” command
In order to execute an EFI application, we need to bridge the gap between U-Boot’s notion of executing images and EFI’s notion of doing the same. The best path forward IMHO here is to stick completely to the way U-Boot deals with payloads. You manually load them using whatever method to RAM and then have a simple boot command to execute them. So in our case, you would do
# load mmc 0:1 $loadaddr grub.efi
# bootefi $loadaddr
which then gets you into a grub shell. Fdt information known to U-boot via the fdt addr command is also passed to the EFI payload.
Tom Rini of the U-Boot project also just posted a message saying that the EFI patches have been mostly applied:
EFI loader support largely enabled
What I mean by the subject is that with the EFI loader patches enabled U-Boot itself (not SPL) now includes the EFI loader and required bits on ARM/aarch64. This is in general I think a good thing. I’ve however disabled it on a few boards due to size constraints. This is an average gain of ~12KiB in U-Boot proper. I fully expect a number of platform patches opting out of this support due to it just not being a real usecase and I am agreeable to talking about making it not enabled by default. So, lets kick things off.
For more information, see the U-Boot sources or mailing list archives:
5.0.14 is a maintenance release. The prior release, 5.0.12, had a fix to their EFI support.