Xerocrypt’s FreeBSD security overview

Enno Ray points out that The Krypt has a new article focusing on FreBSD security features:

Even if you are a Linux-only person, who doesn’t care about FreeBSD, you still may want to read this to get an understand of Matthew Garret’s BSD-based sedurelevel patch that improves Linux Secure Boot security. 🙂



Quoting Wikipedia, “Kylin is an operating system developed by academics at the National University of Defense Technology in the People’s Republic of China since 2001. It is named after the mythical beast qilin. The first versions were based on FreeBSD and were intended for use by the Chinese military and other government organizations. With version 3.0 Kylin became Linux-based, and there is a version called NeoKylin which was announced in 2010. In 2013, it was announced that a new Linux-based operating system with the same name would be released using Ubuntu. The first version, Ubuntu Kylin 13.04, was released on 25 April 2013.

QZ.com has a new review of this OS, including some screenshots:


I still don’t know what firmware it uses. I’ve not found the source code yet. 😦

More Information:


Using FreeBSD, ZFS, and UEFI

Jashank Jeremy wrote an article on using FreeBSD, ZFS, GPT, and UEFI, on a 64-bit system.

Apparently, the trick to is to use GRUB’s kFreeBSD mode. Full information here:

Hmm, WordPress imbeds the entire source file listing of a Git.Github URL. So I’m splitting this URL, you’ll have to combine it yourself:


Also check out the reply from Felix Khrohn on Jashank’s Twitter post, with an URL to alternative method by Ganael Laplanche.

UEFI for OpenBSD??

Hmm, I was under the impression that of the BSDs, only FreeBSD supported UEFI. (As well as MacOSX, of course.) But it appears that despite Theo’s previous comments on UEFI 🙂 that there might be some UEFI support in OpenBSD eventually:

From last year, GSOC’14 for OpenBSD (UEFI and GPT), I’ve not studied to see if these have been upstreamed yet:

From 2 days ago, a new OpenBSD-centric boot loader:
It looks like the latter project needs some hardware help, besides the author’s VIAO, if you can help them out…

New HardenedBSD release

A new release of HardenedBSD is available: v28 version of 10-STABLE as well as 11-CURRENT.

HardenedBSD is a security-enhanced fork of FreeBSD, created in 2014 by Oliver Pinter and Shawn Webb. HardenedBSD aims to implement innovative exploit mitigation and security solutions for FreeBSD. The project works with upstream FreeBSD and any other FreeBSD-based project to include any security improvements. NanoBSD is the embedded subset of FreeBSD. FreeBSD — at least the last time I checked — was the only BSD distro that supports UEFI. Recently, HardenedBSD 11-CURRENT was released:

The AArch64 port of FreeBSD has been progressing well. I’ve not built HardenedBSD for AArch64 myself yet, but it appears that someone can, there’s a VM version at least:

ZFS for FreeBSD’s for UEFI boot loader

From the FreeBSD Quarterly Status Report, FreeBSD’s boot loaders have a patch to support ZFS booting:

ZFS Support for UEFI Boot/Loader: UEFI-enabled boot1.efi and loader.efi have been modified to support loading and booting from a ZFS filesystem. The patch currently works with buildworld, and successfully boots on a test machine with a ZFS partition. In addition, the ZFS-enabled loader.efi can be treated as a chainloader using ZFS-enabled GRUB. The work on boot1.efi also reorganizes the code somewhat, splitting out the filesystem-specific parts into a modular framework. Open tasks:
1) More testing is needed for the following use cases: ZFS with GRUB+loader.efi, ZFS with boot1+loader.efi, UFS with boot1+loader.efi (to test the modularization of boot1.efi)
2) Have boot1.efi check partition type GUIDs before probing for filesystems.
3) Get patch accepted upstream and committed.

More Information:

Linux distros (and FreeBSD): join the UEFI Forum

Hey Linux/FreeBSD distros: it’s great that you’ve got UEFI support including Secure Boot certs. But that’s not enough, you need to join the UEFI Forum, and help evolve UEFI to be more Linux-friendly.

Right now, the last time I checked, the only Linux distros that had joined were: Canonical (Ubuntu), Red Hat, and SuSE. As well as Linaro. Excluding SuSE and Redhat’s commercial products, that means that Ubuntu, Fedora, and OpenSUSE are the community Linux distros that may have the best UEFI support.

UEFI Forum members have access to:
* member-only communications (web forums)
* member-only invites to meetings/events (including the 1-3 plugfests they do each year).
* member-only access to software and specs the public doesn’t have.
* access to file bugs/change requests, which the public cannot do.

I think you get access to their non-public trunk, a subset of which is exported to the public as TianoCore, but I’m not sure. (Hypocritically, I’m not a member yet, still working on it, blocking on some new company infrastructure.)

If you join, you can help evolve and improve UEFI, and have early access to UEFI resources so your distros can be ready for any changes. You can attend the plugfests and do interop testing with other UEFI products/projects, to find problems before your users have to see them.

If you don’t join, you’ll be constantly reacting to UEFI Forum releases, have less resources than UEFI Member distros have, and if there’s a problem all you can do is whine and blame Intel and/or Microsoft, when you should look into the mirror instead.

The Linux Foundation should help enable community distros, which don’t have large corporations to back their membership, to get involved as well. The Free Software Foundation should join and participate, instead of keeping their heads in the sand and wish everyone would stop using UEFI. Embrace and Extend.

In addition to Linux distros, FreeBSD also supports UEFI, and is not a UEFI Forum member. iX Systems and FreeBSD Foundation: this also applies to you.

You also need to register your distro with the UEFI Forum’s ESP Subdirectory Registry, so you can have some UEFI binaries (boot loader, etc.) in a well-known location. Ex, if Debian’s cbootstrap gets ported to a UEFI Application, then \EFI\Debian\cbootstrap.efi would be an example of where the file would be stored. Right now, Debian is registered, but not a member of the UEFI Forum!?

Intel, ARM, Linaro, Red Hat, SuSE, and Canonical have been doing a great job improving UEFI so it works better with non-Apple, non-Microsoft operating systems. IMO, more distros need to get involved and help.

More Information:


While I’m on my soapbox, Linux distros should consider some UEFI-centric rescue options in their boot CDs. ALT Linux Rescue ISOs include rEFInd boot manager, and let you optionally jump into UEFI Shell. You could use UEFI-aware GRUB for this, instead of rEFInd. Additionally, it would be nice to also give access to running: FWTS (FirmWare Test Suite), Intel CHIPSEC to test the hardware/firmware for security. It would also be nice to include the UEFI port of CPython 2.7x, along with the UEFI Shell, for more powerful diagnostic abilities. Distro installers should also consider installing UEFI Shell and UEFI Python and CHIPSEC onto system’s ESP, in an advanced mode, not just let them access via install ISO. Of course, there are security issues by enabling extra Pre-OS tools, user would need to opt-into all of this. Intel’s LUV-live, which Linaro is porting to AArch64, contains BITS (BIOS Interface Test Suite), FWTS, CHIPSEC all in one convenient location. I hope other Linux distros emulate some of LUV-live’s diagnostic and rescue abilities.

Secure Boot strength varies by Linux implementation

[UPDATE, with input from readers, see EOM. Thanks!]

UEFI Secure Boot is a build-time feature of UEFI that helps secure the boot process from some boot-time attacks, optionally using TPM hardware if available. Secure Boot became widespread on Windows hardware during Windows 8 timeframe. Windows aside, other operating systems have to support UEFI Secure Boot. Linux supports UEFI and UEFI Secure Boot (as does FreeBSD). Different Linux distributions have different Linux kernels, with different versions, different patchsets, and different build-time directives enabled. So, Fedora’s Linux kernel is different than SuSE’s Linux kernel, etc.

I saw a recent comment from a UEFI security researcher who had been building a Linux liveboot CD and running CHIPSEC — which includes a native Linux kernel driver, and running it on UEFI systems with Secure Boot enabled.

“Ubuntu appears to have shim and do secure boot but not enforce kernel module signing.”

This Ubuntu behaviour was a change in behaviour from the Fedora-based systems the researcher was used to using. I was curious about the difference in distros w/r/t enforcing kernel module signing. So I asked on the FirmWare TestSuite (FWTS) list if there was a test for this. Roderick W. Smith of Canonical — and author of rEFInd boot manager and the definitive Linux boot loader/manager reference on RodsBooks.com — replied clarifying the situation:

“Yes, that’s correct. Ubuntu’s kernel doesn’t attempt to enforce Secure Boot policy beyond the main kernel file; once the kernel’s loaded, it’s possible to load an unsigned kernel module. Fedora, as you inferred, does require signing of kernel modules. Fedora’s approach is arguably more secure, since an attacker can’t load a malicious kernel module once the system has booted, but leads to problems with third-party kernel modules, like the in-kernel portions of nVidia and ATI/AMD video drivers. FWIW, the decision to do it this way was made before I joined Canonical, so I’m not sure who made the decision.”

Ivan of Canonical replied with more information:

“On Linux, two stage booting has implemented for secureboot. First stage is firmware boot to shim and then shim will take care to check signature and boot with grub and kernel. Booting with/without kernel signed is under shim and grub implementation, Ubuntu provides the singed kernel in official releases, and would like to keep the flexibility for user to build their kernel, so Ubuntu doesn’t block booting when user uses unsigned kernel.”

The security researcher who reported this speculated that Canonical’s policy may be due to them not wanting to put their distro signature (or perhaps worry about license issues in doing so) on some 3rd party (non open) binary.

As I understand things, this is beyond the strict “UEFI Secure Boot” definition, and on to what OS-centric post-UEFI Secure Boot security techniques it will implement. I guess some call it “OS Secure Boot” to differentiate it from “UEFI Secure Boot”, but I don’t see any formal definition for that term.

I wish there was more precise information about Secure Boot implementation from each Linux distro. System administrators and technical support engineers will need to know these nuances, as will security researchers. Pehaps Linux Foundation or UEFI Forum — or some Wikipedian(s) — could help with a comparison of Secure Boot on different OSes? Perhaps FWTS or CHIPSEC could have a test to check? Perhaps the UEFI Forum could note these nuances at their next plugfest, and setup test cases combinining Linux OSVs with a test case that loads dynamically load native OS drivers: perhaps using CHIPSEC as the test case may suffice, it loads a native helper driver.

So, don’t just look at if Secure Boot is enabled or not, look at what Linux OS you’re using, and how it implements Secure Boot. And remember attackers are also making this choice, and looking for your softer Linux targets, so be more careful when using those systems.


Updated information:

The reason this issue came up is that the researcher was using Intel CHIPSEC, which when run on Linux it uses a Linux kernel module. Unlike most drivers, which get loaded when OS initializes, then stay loaded, the CHIPSEC driver behaves differently. The CHIPSEC userland Python app compiles the kernel module, and loads the module when it starts, then unloads the driver when it finishes (because the driver enables risky things, see it’s warning.txt). On Fedora, this kind of CHIPSEC driver loading behavior will not work, with Secure Boot enabled, until you setup moklist and sign the module. By contrast with Fedora, on Ubuntu, CHIPSEC is able to load the unsigned driver without the user having to change anything (convenience). Here’s more information on how Fedora does it’s module signing process:

FreeBSD 10.2 beta1 released

Today FreeBSD announced availability of release 10.2-BETA1.

Amongst the new features/changes in this release, for firmware these changes are interesting:

* The uefisign(8) utility has been added. [r282974] (Sponsored by The FreeBSD Foundation)
* The acpi(4) subsystem has been updated to version 20150515. [r284460]
* Throttling via ACPI and P4TCC via device.hints(5) have been turned off by default. [r276986]
* The boot loader has been updated to support entering the GELI passphrase before loading the kernel. To enable this behavior, add geom_eli_passphrase_prompt=”YES” to loader.conf(5). [r281843]
* The memory test run at boot time on FreeBSD/amd64 platforms has been disabled by default. [r283262] (Sponsored by The FreeBSD Foundation)

Besides the above changes, there’ve also been a variety of iSCSI changes, unclear if this impacts UEFI’s iSCSI at all. And the Hyper-V drivers have been updated, sponsored by Microsoft’s Open Source Technology Center. [I am ignorant to Hyper-V technology, I guess I need to check how open source Hyper-V code in NanoBSD  impacts UEFI.]

More Information:

PS: Unrelated to FreeBSD release, appears Intel CHIPSEC team is about to release 1.2.1, there is activity on their Github site:


Intel System Studio now targets FreeBSD

Intel System Studio (ISS) is a GUI IDE to build embedded systems. ISS normally is only available on Windows and Linux. Now it is also available on FreeBSD!

Intel® System Studio (ISS) 2016 for FreeBSD* Beta provides a comprehensive embedded tool suite solution for developing, optimizing, tuning and deploying 64-bit system and application C, C++ code running natively on FreeBSD* host systems. This product release includes the following components:

  • Intel® C++ Compiler 16.0 Beta for FreeBSD* systems
  • Intel® VTune™ Amplifier 2016 Beta for Systems for FreeBSD* Targets

ISS includes the Intel C Compiler, the only C Compiler that targets EBC, the EFI Byte Code. Normally ISS is a commercial-only product, but they sometimes have a shareware-style free edition available during beta periods. AFAIK, there is not a free version of Intel C Compiler.

Thanks to the FreeBSD News site for finding this information.

More Information:



Recent FreeBSD firmware improvements

Like Linux, FreeBSD now also supports UEFI. PC-BSD and TrueOS are FreeBSD-based, as is NanoBSD, the embedded subset of FreeBSD.

Besides UEFI pre-OS tool support, FreeBSD also has Forth-based OpenFirmware /boot/loader, with numerous diagnostic commands (autoboot, bcachestat, boot, echo, heap, help, include, load, load_geli, ls, lsdev, more, pnpscan, read, reboot, set, show, unload, unset, ?).

Earlier this week, PC-BSD 10.1.2 has been released. Amongst the changes I notice two firmware-related improvements for this release:

* Support for encrypted iSCSI backups via Life-Preserver, including support for bare-metal restores via installer media

* Improvements to Online Updater, along with GRUB nested menus for Boot-Environments

Firmware changes aside, they’ve been adding some interesting security features: /-level encryption for ZFS, PersonaCrypt Utility, with Stealth Mode, Tor mode for firewall, etc.

More information:

10.1.2 release:

FreeBSD and UEFI:
http://bsdmag.org/beyond-bios-the-extended-firmware-interface -efi/


Sage Engineering updates Minnow firmware

Sage Engineering maintains a Coreboot-based, SeaBIOS payload-based firmware for the Intel MinnowBoard MAX.

Today, they’ve announced an updated release. This update allows for flashing the boot image without a hardware device.

The binary SageBIOS boot ROM image, which is flashed on the development board’s SPI Flash device, is based on the Intel Firmware Support Package (Intel FSP) and coreboot open source initialization. The SageBIOS OSP replaces UEFI firmware that comes installed on both versions of MinnowBoard MAX and will support booting a greater variety of operating systems, including FreeBSD and a variety of RTOS, as well as legacy operating systems such as older versions of Microsoft Windows and even DOS. The SageBIOS OSP will support all the operating systems supported by the native UEFI firmware, such as Windows and Linux. In addition, the SageBIOS OSP will boot both 32-bit and 64-bit operating systems with a single boot image.

The download of the “demo ROM” is free, but email registration is required.
More information: