swissarmy-grubefipxe – A configuration for netbooting various linux distros using PXE/EFI/GRUB

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.[…]

https://github.com/vittorio88/swissarmy-grubefipxe

MountEFI – mac tool to select drive containing an EFI to mount

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.

def custom_quit():
     head(“MountEFI”)
     print(“by CorpNewt\n”)
     print(“Thanks for testing it out, for bugs/comments/complaints”)
     print(“send me a message on Reddit, or check out my GitHub:\n”)
     print(“www.reddit.com/u/corpnewt”)
     print(“www.github.com/corpnewt\n”)
     print(“Have a nice day/night!\n\n”)
exit(0)

https://github.com/corpnewt/MountEFI

FAT-EFI: FAT EFI loader plugin for Hopper Disassembler

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.[…]

https://github.com/pascalwerz/FAT-EFI

https://www.hopperapp.com/

Similar: https://github.com/0xc010d/EFIFatBinary.hopperLoader

UEFI-var-in-disk: Inject the UEFI variable in the first sector of hard disk

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

usage text:
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

https://github.com/NeoCui/UEFI-var-in-disk

proposal: add Security Version to Linux Shim

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.

Security Version

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.[…]

https://github.com/lcp/shim/wiki/Security-Version

https://marc.info/?l=linux-efi&m=151246813626512&w=2

PS:  Hmm, Gmane’s linux-efi links aren’t working for me.
http://dir.gmane.org/gmane.linux.kernel.efi

efivalidate (and mojo_thor)

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

https://github.com/rickmark/efivalidate

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)

https://github.com/rickmark/mojo_thor

https://rickmark.me/

UEFIThreads: EFIDroid’s port of LittleKernel’s thread library for UEFI

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[0] 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[1]. 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.

[0] https://github.com/Openwide-Ingenierie/GreenThreads-UEFI
[1] https://github.com/efidroid/uefi_edk2packages_EFIDroidLKLPkg/tree/master/UEFIThreads
http://efidroid.org/

https://github.com/littlekernel
https://github.com/littlekernel/lk/wiki/Introduction
https://github.com/littlekernel/lk/blob/master/kernel/thread.c

https://developer.qualcomm.com/qfile/28821/lm80-p0436-1_little_kernel_boot_loader_overview.pdf


https://android.googlesource.com/kernel/lk/

Full message: 2017-11-02 post on EDK2-devel.

Duo Labs releases EFIgy 10.13

https://github.com/duo-labs/EFIgy/

gnu-efi-applets

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.

Name: gnu-efi-applets
Version: 3.0.3
Release: 3
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 <bluebat@member.fsf.org> – 3.0.3
First release

https://github.com/bluebat/gnu-efi-applets
https://github.com/bluebat/gnu-efi-applets/tree/master/efilibc.applets
https://github.com/bluebat/gnu-efi-applets/tree/master/efilibc

 

Apple EFI malware triad: Mojo/Thor/Loki?

Mojo / Thor / Loki are a triad of malware that infects the EFI of Apple MacBooks.[…]

https://github.com/rickmark/mojo_thor

more from Duo on Apple EFI security

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:

https://docs.google.com/spreadsheets/d/1qGRVF1aRokQgm_LuTsFUN2Knrh0Sd3Gp0ziC_VIWqoM/edit#gid=0

Apple macOS automatic EFI checks

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.[…]

High Sierra automatically checks EFI firmware each week

AFAICT, the article references Tweets from earlier today that appear to have subsequently been deleted from Twitter.

new Apple tools: eficheck (and nvm)

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]]

https://pikeralpha.wordpress.com/2017/08/18/apple-to-cleanup-a-bios-region-of-your-ami-and-phoenix-bios/
https://www.apple.com/macos/sierra/
https://en.wikipedia.org/wiki/MacOS_High_Sierra
https://www.macrumors.com/roundup/macos-10-13/
https://firmwaresecurity.com/2017/01/25/eficheck

Maybe someday there’ll be more info on eficheck, if you find any manpage or other info, please leave a Comment.
https://www.apple.com/us/search/eficheck
https://twitter.com/search?q=eficheck&src=typd

Setting up Mac for EFI development

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.[…]

https://0xcc.re/setup-efi-development-environment-on-mac-osx-sierra-10-12-x/

apple_set_os.efi: unlock Intel IGD on MacBook Pro

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.[…]

https://github.com/0xbb/apple_set_os.efi

More info:
https://lists.gnu.org/archive/html/grub-devel/2013-12/msg00442.html

Linux Kernel: exclude EFI from KASLR VA space randomization

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.