This is a little side-project of mine to be able to netboot various Operating Systems using EFI based computers and GRUB over PXE. I have this running on my QNAP NAS, but I believe almost any decent NAS has the requirements to run this. This project was born out of my disdain for flashing distros to USB keys.[…]
This Mac-centric bash script has been rewritten as a Mac-centric Python script:
“A more robust edition of my previous MountEFI script. Added my usual collection of disk functions – plus some experimentation with callback functions.
print(“Thanks for testing it out, for bugs/comments/complaints”)
print(“send me a message on Reddit, or check out my GitHub:\n”)
print(“Have a nice day/night!\n\n”)
android-efi is a simple EFI bootloader for Android™ boot images. It accepts the partition GUID of an Android boot partition on the command line, loads the kernel, ramdisk and command line and finally hands over control to the kernel.[…]
Puppet module for managing EFI boot order
This project is a FAT EFI loader plugin for Hopper Disassembler. Apple uses an extension to the standard PE format for EFI binaries to allow FAT EFI binaries that contain both 32 and 64 bits executables. It is very similar to the FAT format, except for a different magic number and for little endianness. This plugin allows to read these FAT EFI binaries with Hopper Disassembler.[…]
Bluntly, I’m not sure what this month-old project does yet, the title/tagline sounds more interesting than the usage, and I’ve not done a code review yet.
Inject the UEFI variable in the first sector of hard disk
efi2disk version %s\n”, TOOL_VERSION);
usage: efi2disk [options]
-r | –read Read UFEI variable information
-V | –version return version and exit
-h | –help show help/usage
Gary Ching-Pang Lin of SuSE has submitted a proposal for Linux kernel and Shim to include a Security Version. In addition to below shim wiki page, there is active discussion on this on the Linux-EFI list.
When a vulnerability is found, every distro will release the patch as soon as possible and push it into the update channel. However, since the signature of the old kernel is still valid, the attacker may trick the user to boot the old and insecure kernel to exploit the system. For the system with UEFI Secure Boot, although the admin can add the hashes of the insecure kernels into MokX, it could be burdensome to do this in large scale. Besides, it’s almost impossible to obsolete the kernels before a certain version. Not to mention that the old kernel sometimes might be useful for debugging. To keep the system secure and also flexible, we propose “Security Version”. The basic concept of Security Version is to use a whitelist to record the “version” of the latest known secure linux kernel. If the “version” of the kernel is lower than that in the whitelist, then the kernel is considered as “not secure”. The “version” in the whitelist can only be incremented monotonically unless the user decides to lower it.[…]
PS: Hmm, Gmane’s linux-efi links aren’t working for me.
Simple EFI boot manager
sEFI is simple boot manager for UEFI capable computers. It uses simple C language and GNU-EFI library.
Differences from other boot managers:
* file browser to select efi applications
* really simple structure of config files
Rick Mark has released efivalidate, a macOS-centric Ruby-based EFI checking tool. Also, by same author, Mojo_Thor project has activity. I thought it was a one-time drop, but it is actively being updated:
efivalidate is a ruby utility to take a given input EFI payload from macOS and to compare it against Apple’s validation schema. Being written in ruby this can occur off-box to ensure that the utility itself hasn’t been compromised
Loki / Thor / Mojo are a triad of Apple internal tools and malware that infects the SMC, EFI and macOS of Apple MacBooks. It is believed that direct access to the hardware is gained by re-flashing the Thunderbolt controller (via ThorUtil)
UEFI is event-based, not thread-based. Earlier this month, Michael Zimmermann of the EFIDroid project posted a message on the EDK2-devel list about EFIDroid’s thread library support for UEFI, which is based on the Little Kernel threads implementation, and comparing it to the GreenThreads-UEFI project. Edited (footnotified) version of Michael’s message below.
IMO this [GreenThreads-UEFI] library has some crucial problems like changing the TPL during context switching. For my project “EFIDroid” I’ve invested many months analyzing, testing and implementing my own threading implementation based on LK(LittleKernel, a MIT licensed project) threads and get/set -context. The result is a pretty stable implementation which can even be used in UEFI drivers. I’m currently using this lib for my LKL(LinuxKernelLibrary) port to be able to use linux touchscreen drivers in UEFI – so you could say it has been well tested. The only “problem” is that it only supports ARM right now and that the get/set context implementation was copied (and simplified) from glibc which means that this part is GPL code.
From the Little Kernel web site:
Who is using LK?
* LK is the Android bootloader and is also used in Android Trusted Execution Environment – “Trusty TEE” Operating System.
* Newer Android phones have some chance of LK running all the time alongside Linux.
* A few ARM SoC manufacturers use LK as their default bootloader such as DragonBoard 410c based on Qualcomm Snapdragon 410 processor.
* The Fuchsia Operating System’s microkernel, Zircon is based on LK.
Full message: 2017-11-02 post on EDK2-devel.
The GNU-EFI-Applets project appears to be about a month old. There are a LOT of UEFI applications ported in this project, including a LISP interpreter. It also includes “efilibc”, another LibC implementation from musl or the EADK libraries. These build with GNU-EFI, not Tianocore/EDK2 build environment.
Summary: Building Applets using GNU-EFI
Some missing applets for the EFI system.
Building Environment for building GNU-EFI applets.
Tue Sep 19 2017
Wei-Lun Chao <firstname.lastname@example.org> – 3.0.3
Mojo / Thor / Loki are a triad of malware that infects the EFI of Apple MacBooks.[…]
Nice, in addition to an upcoming new EFI tool, it appears Duo has some defensive advise, using OSQuery, Puppet, and Chef. Click on the first tweet below for an image from their upcoming presentation.
Note that Teddy Reed is giving a presentation on OSQuery in November at Usenix LISA:
Pepjin’s Apple EFI version spreadsheet:
High Sierra automatically checks EFI firmware each week
Upgrading to High Sierra brings a new and significant security feature: your Mac will automatically check its EFI firmware. In a series of tweets, Xeno Kovah, one of the three engineers responsible for the new tool, has outlined how this works.[…]
AFAICT, the article references Tweets from earlier today that appear to have subsequently been deleted from Twitter.
Apple has apparently created a tool for examining Apple Mac EFI firmware, called eficheck. As I understand things, it was released, then pulled due to some issues (bugs?), and is apparently now avabilable in latest macOS updates. Also, it sounds like there might be another tool for NVMe diagnostics.
usage: eficheck: [–save -b] [ –cleanup -b] [–generate-hashes [-b] [-p]] [–integrity-check [-h [-b]]] [–show-hashes [-h] | [-b]]
Setup EFI Development environment on Mac OSX Sierra (10.12.X)
Mikal Villa Mikal Villa • 07/10/2017
Oh no! a lot of text. Well, luckly half of the post is troubleshooting. EFI development setup is easy 🙂
Okay, before starting this guide you should have some tools installed already.[…]
apple_set_os.efi: Tiny EFI program for unlocking the Intel IGD on the Macbook Pro 11,3 for Linux and Windows. It has been made to be easily chainloaded by unmodified EFI bootloader like Grub, rEFInd etc. The Macbook Pro 11,3 model’s EFI is switching off the Intel GPU if you boot anything but Mac OS X. So a little trick by faking the OS identifiction is required to make all hardware accessible. All credits belong to Andreas Heider who originally discovered this hack.[…]
Greg Kroah-Hartman of the Linux Foundation submitted version 4.10 of a 81-part(!) patch to the Linux kernel by Baoquan He of Red Hat.
[PATCH 4.10 65/81] x86/mm/KASLR: Exclude EFI region from KASLR VA space randomization
4.10-stable review patch. If anyone has any objections, please let me know.
commit a46f60d76004965e5669dbf3fc21ef3bc3632eb4 upstream.
Currently KASLR is enabled on three regions: the direct mapping of physical memory, vamlloc and vmemmap. However the EFI region is also mistakenly included for VA space randomization because of misusing EFI_VA_START macro and assuming EFI_VA_START < EFI_VA_END. (This breaks kexec and possibly other things that rely on stable addresses.) The EFI region is reserved for EFI runtime services virtual mapping which should not be included in KASLR ranges. In Documentation/x86/x86_64/mm.txt, we can see:
ffffffef00000000 – fffffffeffffffff (=64 GB) EFI region mapping space
EFI uses the space from -4G to -64G thus EFI_VA_START > EFI_VA_END, Here EFI_VA_START = -4G, and EFI_VA_END = -64G. Changing EFI_VA_START to EFI_VA_END in mm/kaslr.c fixes this problem.
More info: see the linux-efi/linux-kernel list.