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.