Tool review: UBU-helpers

Tool Review: UBU-helpers

[UPDATED, with feedback from reader. Thanks!]

UBU-helpers is a collection of tools used to examine UEFI binaries. The UBU-helpers code is portable C, built with CMake, so it should work on most UNIX systems as well as other common platforms with decent C compilers. The project is maintained: the tools were updated a few days ago. Currently there three tools: Hex Find (hexfind), Find Version (findver), and Driver Version (drvver).

1) Hex Find (hexfind) is a simple tool that searches for a pattern in a file.

hexfind v0.1.2
Usage: hexfind PATTERN FILENAME

2) Find Version (finder) is simple tool that also searches for version-based patterns in a file.

findver v0.3.2
Prints version string found in input file
Usage: findver prefix pattern offset end_marker max_length FILE
Options:
prefix      – Prefix string, ASCII symbols
pattern     – Pattern to find, hex digits
offset      – Offset of version string, integer
end_marker  – Pattern that marks end of version string, 2 hex digits
max_length  – Maximum length of printed version string, integer
num_location- Number of location, integer

3) Driver Version (driver) searches for multiple UEFI drivers/applications via hardcoded string/offset searches.  It — as do the other two tools — uses a Boyer-Moore-Horspool algorithm for it’s find algorithm.

drvver v0.19.2
Reads versions from input EFI-file
Usage: drvver DRIVERFILE
Support:
GOP driver Intel, AMD, ASPEED.
SATA driver Intel, AMD, Marvell
LAN driver Intel, Realtek, Broadcom

Here’s the printf statements of what drvver recognizes:

EFI GOP Driver SandyBridge – 2.0.%s
EFI GOP Driver IvyBridge   – 3.0.%s
EFI GOP Driver Haswell     – 5.0.%s
EFI GOP Driver Broadwell   – 5.5.%s
EFI GOP Driver CloverView  – 6.0.%s%S
EFI GOP Driver ValleyView  – 7.%c.%s%S
EFI GOP Driver CherryView  – 8.0.%s
EFI GOP Driver SkyLake     – 9.0.%s
EFI GOP AMD                – %s_signed
EFI GOP AMD                – %s
EFI GOP-in-OROM ASPEED     – %x.%02x.%02x
EFI GOP ASPEED             – %x.%02x.%02x
EFI IRST RAID for SATA     – %s
EFI AMD RAID               – %s
EFI AMD Utility            – %s
EFI AMD Utility            – %c.0.0.%c%c
EFI IRSTe RAID for SCU     – %s
EFI IRSTe RAID for sSATA   – %s
EFI IRSTe RAID for SATA    – %s
EFI Marvell SATA RAID      – %x.%x.%x.%04x
EFI Marvell SATA AHCI      – %x.%x.%x.%04x
EFI Intel 40GbE UNDI       – %x.%x.%02x
EFI Intel 10GbE UNDI       – %x.%x.%02x
EFI Intel PRO/Server UNDI  – %x.%x.%02x
EFI Intel Gigabit UNDI     – %x.%x.%02x
EFI Intel PRO/1000 UNDI    – %x.%x.%02x
EFI Intel FCoE Boot        – %s
EFI Broadcom UNDI          – %d.%d.%d
EFI Realtek UNDI           – %x.%03x %X%s
EFI Realtek UNDI           – %x.%03X%s
CPU Microcode 040671 BDW   – %02X
CPU Microcode 0306C3 HSW   – %02X
CPU Microcode 0206A9 IVB   – %02X
CPU Microcode 0306A7 SNB   – %02X
CPU Microcode 0306F2 HSW-E – %02X
CPU Microcode 0506E3 SKL-S – %02X
Unknown version GOP Driver
Unknown Intel LAN version.
Unknown Broadcom LAN version.
Unknown Realtek LAN version.
Unknown Realtek LAN version.

If you need to search for specific EFI strings in EFI binaries, these tools might be just what you needed. For more information, see the source code:

https://github.com/LongSoft/UBU-helpers

These tools were created to augment another tool which I’ve not used yet, “UEFI BIOS Updater (UBU)”. Here’s more information on that:

http://www.win-raid.com/t154f16-Tool-Guide-News-quot-UEFI-BIOS-Updater-quot-UBU.html

LinuxCon North America this August in Seattle

LinuxCon North America is happening this August, in Seattle for the first time (I think). A quick look at their schedule shows a variety of interesting presentations related to firmware security:

* Extending the Secure Boot Certificate and Signature Chain of Trust in the OS – Fionnuala Gunter, Hypori
* Resurrecting Internet Booting – Boot Boot, Booting Over the Internet – John Hawley, Intel
* Demystifying ACPI and EFI via Python and BITS – Josh Triplett
* ACPI for Network Switches – Dustin Byford, Cumulus Networks
* Tying TPMs Throughout The Stack – Matthew Garrett, CoreOS
* Turtles All The Way: Running Linux on Open Hardware – Rob Landley
* ACPI 6 and Linux – Rafael J. Wysocki, Intel
* The Bare-Metal Hypervisor as a Platform for Innovation – Russell Pavlicek, Citrix
* Suspend/Resume at the Speed of Light – Len Brown, Intel

Josh Triplett on BIOS BITS sounds especially interesting. It’ll be interesting to see if the boot boot reboot will get integrated with UEFI HTTP Boot support.

More information:
http://events.linuxfoundation.org/events/linuxcon-north-america
http://events.linuxfoundation.org/events/linuxcon-north-america/program/schedule

Replicant on mobile device security

The Replicant project is a Free Software-specific fork of Android, which focuses on users’ freedoms, and privacy/security. They try to get Android running without any firmware- or OS-level “blobs”, which gives them technical perspectives that most don’t have. They have a document which gives a decent introduction to mobile device security, including hardware, firmware, OS, and app issues, and about security issues of mobile baseband chips.. The advice is focused for someone using Replicant, but the app advice is applicable to most Android users.

More Information:

http://www.replicant.us/freedom-privacy-security-issues.php

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:
https://www.freebsd.org/relnotes/10-STABLE/relnotes/article.html
https://lists.freebsd.org/pipermail/freebsd-stable/2015-July/082704.html

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

https://github.com/chipsec/chipsec

VirtualBox 5.0 released

Oracle relased version 5.0 of VirtualBox yesterday. I don’t see any firmware features listed in the press, and I’ve not had a chance to do a code review of the new code yet. It has improved CPU and USB 3.0 support, at minimum.

QEMU is the main platform for running UEFI’s virtual firmware: OVMF. But Xen, KVM, and VirtualBox also support OVMF, to some degree. VirtualBox can also be recompiled with EFI-specific build directives to enable additional UEFI diagnostics.

https://www.oracle.com/corporate/pressrelease/oracle-vm-virtualbox-5-070915.html

https://blogs.oracle.com/virtualization/entry/oracle_vm_virtualbox_5_07

(In somewhat related news, back in March, Oracle’s Linux distro got Secure Boot support.)

https://blogs.oracle.com/wim/entry/secure_boot_support_with_oracle

 

OpenStack’s hardware introspection service 2.0 released

Dmigtry Tantsur of Red Hat announced version 2.0 of OpenStack’s hardware introspection service was released today on the openstack-announce list.

“This is an auxiliary service for discovering hardware properties for a node managed by OpenStack Ironic. Hardware introspection or hardware properties discovery is a process of getting hardware parameters required for scheduling from a bare metal node, given it’s power management credentials (e.g. IPMI address, user name and password). A special ramdisk is required to collect the information on a node. The default one can be built using diskimage-builder and ironic-discoverd-ramdisk element. Highlights of this release:

* Main Python module was renamed to ironic_inspector
* Client library was split away to a separate project
* edeploy plugin was removed in favor of more generic one called ‘extra_hardware’
* Processing hooks interface was changed
* The way we return API errors was changed to better match Ironic one
* Removed deprecated /v1/discover endpoint
* All options (except for ‘database’) were moved to sections instead of  using ‘discoverd’ for everything
* oslo.db configuration should be used instead of ‘discoverd.database’  option
* keystonemiddleware options should be used instead of reusing ‘ironic’  credentials for checking authentication
* Deprecated ‘authenticate’ opt in favor of ‘auth_strategy’
* Explicit green thread pool is used instead of just launching new threads
* NodeInfo class became more helpful for hooks
* Now it’s possible to hook into processing chain when node is not found
* Inspector no longer checks for Ironic presence on start up as it was  causing problems in real life
* SSL/TLS Support”

More Information:

https://github.com/openstack/ironic-inspector
https://pypi.python.org/pypi/ironic-inspector/2.0.0
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-announce

EDK-II specs updated

[

UPDATE: Below I complain about lack of an announce mechanism to find these updates; TianoCore has an RSS feed that I’ve been neglecting to check, so they have been announcing it, but I’ve not been noticing…

http://www.tianocore.org/news/feed.xml

]

Today, the EDK-II specs were revised.

“Announcing the 1.25 Updates to the EDK II Specifications (BUILD, DSC and FDF). Also Update to Visual Forms Representation (VFR) V 1.9.”

(I stumbled upon announcement on web page by accident; I wish these were announced on edk2-devel or somewhere else more easily-discoverable.)

More Information:

https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Specifications

Intel Skylake release dates leaked

Jeff Thomas at Sage Engineering wrote a blog post yesterday on the new Intel Skylake board.

(Sage is an open source-friendly IBV, they focus on coreboot and Chrome OS, and know a lot more about AMD platforms than I know. Jeff is an active blogger, and a good source of industry news.)

https://www.se-eng.com/2015/07/intel-skylake-comes-out-swinging-aug-5-with-core-i7-and-core-i5-processors/

On a somewhat related note, from an open source OS-level perspective, Skylake has graphics that require non-free firmware blobs, which is IMO unfortunate:
https://01.org/linuxgraphics/intel-linux-graphics-firmwares
https://lists.debian.org/debian-x/2015/06/msg00039.html
https://www.phoronix.com/scan.php?page=news_item&px=Intel-SKL-BXT-Firmware-Blobs

 

FirmWare Test Suite 15.07.00 released

[Update: Colin King also blogged about this release:
http://smackerelofopinion.blogspot.com/2015/07/new-acpi-table-tests-in-fwts150700.html ]

Today Alex Hung of Canonical announced the latest release of FWTS, the FirmWare Test Suite.

Tar: http://fwts.ubuntu.com/release/fwts-V15.07.00.tar.gz
PPA: https://launchpad.net/~firmware-testing-team/+archive/ubuntu/ppa-fwts-stable
Release Notes: https://wiki.ubuntu.com/FirmwareTestSuite/ReleaseNotes/15.07.00

Changes to existing Features:
* –uefi and –acpi options renamed to –uefitests and –acpitests
* ACPI table tests in the acpitables test have been moved into specific ACPI tests.

New Features:
* acpi: acpidump: update TCPA table and acpidump accordingly
* acpi: add ACPI TCPA test
* acpi: add XENV table test
* lib: fwts_framework: Append “tests” to –uefi and –acpi
* live-image/fwts-frontend-text: update to –uefitests and –acpitests
* lib: acpi, acpidump: rename slit tables types
* lib: acpi: add in new GICC table fwts_acpi_table_gicc_affinity
* acpi: add SRAT table sanity checking (LP: #1464658)
* acpi: add BERT table sanity checking (LP: #1464712)
* lib: acpi: Add in GAS address types
* acpi: add ECDT table sanity checking (LP: #1464716)
* lib: acpi: Add support for the SPMI table
* acpi: add ACPI SPMI table sanity checking (LP: #1465256)
* acpi: add ACPI SLIT table sanity checking (LP: #1465276)
* lib: acpi: Add support for the HEST family of ACPI tables
* acpi: add ACPI HEST table sanity checking (LP: #1465379)
* acpi: Add BOOT table test (LP: #1465435)
* acpi: Add DBGP table test (LP: #1465441)
* acpi: Add DBG2 table test (LP: #1465710)
* acpi: re-orgainise HPET tests
* acpi: move MADT test from acpitables into new MADT test
* acpi: move GTDT test from acpitables into new GTDT test
* acpi: move XSDT test from acpitables into new XSDT test
* acpi: move RSDP test from acpitables into new RSDP test
* acpi: move RSDT test from acpitables into new RSDT test
* acpi: acpitables: remove no-op MCFG test
* acpi: move SBST test from acpitables into new SBST test
* acpi: move FADT test from acpitables into existing FADT test
* acpi: acpitables: remove redundant acpi table checking
* acpi: allow various ACPI table tests to run without root access
* lib: fwts_acpi_tables: fully pad out fixed up ACPI OEM IDs
* acpi: spcr: add missing white space in error messages
* acpi: add ACPI ERST test (LP: #1467835)
* acpi: correct ACPI BGRT table type
* acpi: add ACPI BGRT test (LP: #1467863)
* acpi: add ACPI CPEP test (LP: #1467870)
* acpi: add ACPI FACS test (LP: #1467966)
* acpi: acpidump: add in missing exponent field to SLIC
* acpi: add CSRT ACPI Table test (LP: #1470116)
* acpi: add LPIT ACPI test (LP: #1470184)
* acpi: add WAET ACPI table test (LP: #1470495)
* acpi: add SLIC table test (LP: #1470518)
* acpi: add MSDM table test (LP: #1470538)
* acpi: add UEFI ACPI data table test (LP: #1471698)
* bios: os2gap: remove ancient legacy test (LP: #1470573)

Fixed Bugs:
* acpi: acpidump: update SMM Communication fields on UEFI table
* lib: make acpidump parser more robust (LP: #1471202)
* fwts: cpufreq: fix theoretical division by zero (LP: #1466905)
* acpi: method: remove extraneous “_” in error message
* lib: fwts_klog: fix vector size and handle errors from pcre_exec (LP: #1461520)
* acpi: lib: fwts_acpi_tables: force fixup when loading tables from /sys/firmware
* lib: acpica: compiler: link in missing objects (LP: #1461936)

Two UEFI Form tools, plus one UEFI C Module complexity tool

UEFI has a “Browser”, and the browser shows various “Forms”. The browser is what you see when you get the OEM/IBV BIOS boot menu. OEMs/OBVs can reskin the browser, to add value, so the user experience will vary by vendor. In addition to the OEM/IBV, IHVs and ISVs can also add forms to a system’s browser. Each .efi binary contains resource strings, which get compiled into UEFI’s form language. The raw strings are IFR, Internal Forms Representation. The resulting view for the end user is VFR, Visual Forms Representation.  The UEFI browser is dynamic, you can programatically add new menu options by running an app. If you add foo.efi to your system, when you run the BIOS boot menu you may now see a new entry for the foo device, service, or application. For example, if you plug in a new device, that IHV’s config code will likely be now be in the BIOS boot menu. This is much nicer than having to run a DOS config.exe command (if you even have the ability to boot DOS), or boot into the vendor’s OEM firmware update CD (if they provide one).

At design-time, the EDK-II contains tools to build forms from source code. See TianoCore.org’s EDK-II tools and sample parsing code (in C and Python). Also see Intel SSG’s training courseware and labs, they have UI examples.

http://tianocore.sourceforge.net/wiki/EDK_II_Specifications
http://tianocore.sourceforge.net/wiki/EDK_II_Tools_List
http://tianocore.sourceforge.net/wiki/HII
http://sourceforge.net/projects/edk2/files/Training/TrainingMaterial/

At run-time, existing ROM images or .efi images may have an IFR in the binary. If you don’t have the source code, how do you evaluate the UI included, besides running it?

1) One tool is the “Universal IFR Extractor”, by Donovan6000. This tool can extract the internal forms representation from both EFI and UEFI modules and convert it into a human readable format. It is a Windows-centric tool, being an old-school native GDI GUI appplication written in C++. It may work on *nix via WINE, I’ve not tried it yet.

https://github.com/donovan6000/Universal-IFR-Extractor

2) Another tool is “Language applications for UEFI BIOS”, by William Leara. This was his University of Texas thesis; he is now a BIOS engineer at Dell. Besides the thesis, there is a github project with source code. He created an ANTLR grammar for VFR and a tool that gives an HTML preview of what the form would look like.

3) He also created an ANTLR grammar for UEFI-based C source code, and performs complexity analysis application uses general-purpose and domain-specific measures to give a complexity score to UEFI BIOS modules. This second tool isn’t form-centric, but it is also interesting, perhaps more interesting to some security researchers; it’s a good foundation to create more sophisticated tools of this kind, too…

https://github.com/WilliamLeara/LangAppUEFIBIOS
http://catalog.lib.utexas.edu/record=b8952762~S29
http://repositories.lib.utexas.edu/handle/2152/26306
http://www.basicinputoutput.com/p/aboutme.html

UEFI SMM vulnerability research: SmmBackdoor

Dmytro ‘Cr4sh’ Oleksiuk has been looking into Intel Systems Management Mode (SMM) on UEFI systems. Yesterday he posted a blog with some information on this research, along with some source code. Check out the blog post, it’s a very long document with lots of figures, very good reading.

More Information:

https://github.com/Cr4sh/SmmBackdoor
http://blog.cr4.sh/2015/07/building-reliable-smm-backdoor-for-uefi.html

Apple Bitcode

At their recent annual developer conference, Apple mentioned ‘Bitcode’, a new bytecode technology that may give Apple some hardware independence options in the future.

“Bitcode is an intermediate representation of a compiled program. Apps you upload to iTunes Connect that contain bitcode will be compiled and linked on the App Store. Including bitcode will allow Apple to re-optimize your app binary in the future without the need to submit a new version of your app to the store. For iOS apps, bitcode is the default, but optional. If you provide bitcode, all apps and frameworks in the app bundle need to include bitcode. For watchOS apps, bitcode is required.

Will Bitcode show up on OSX or just be in iOS? Will Bitcode impact Apple firmware? Will Apple firmware use Bitcode instead of EBC (uEFI ByteCode)? I wish I knew, no answers just questions… 😦 Perhaps Bitcode will not impact Apple firmware, and this post is off-topic.

https://developer.apple.com/library/prerelease/watchos/documentation/IDEs/Conceptual/AppDistributionGuide/AppThinning/AppThinning.html#//apple_ref/doc/uid/TP40012582-CH35-SW2

ARM update on GCC and Clang compilers

A few days ago, the ARM Software Dev Tools blog posted their 2015Q2 update on their use of Open Source Toolchains. The post talks about ARM changes in GNU GCC as well as LLVM. It appears they’re getting ready to present at GNU Cauldron in August. Look at their blog for more information. They’ve got some YouTube video and presentation slides, as well.

One thing this blog post clarified to me was what codebase ARM’s C compiler was based on: LLVM Clang:

“The commercial toolchain we offer to our customers, ARM Compiler 6, is in fact based on open source clang.”

More Information:
http://community.arm.com/groups/tools/blog/2015/06/30/open-source-toolchains–arm-status-update-q2-2015

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:

https://www.freebsdnews.com/2015/07/01/intel-system-studio-2016-freebsd-beta/

https://software.intel.com/en-us/articles/intel-system-studio-2016-for-freebsd-beta-0

LibreTrend: new Linux OEM

As reported by Phoronix today, LibreTrend has partnered with Ubuntu Mate, to ship systems with Ubuntu Mate pre-installed. LibreTrend is a relatively new Linux OEM, they apparently launched last year in Portugal. LibreTrend joins the ranks of ThinkPenguin, System76, Purism, Novena, and a few others, OEMs that selling Linux-based systems. Quoting the press release with Ubuntu Mate:

LibreTrend are the designer and manufacturer of the LibreBox, a computer geared towards providing a complete “out of the box” Linux experience, with a heavy focus on hardware compatibility. All the hardware in the LibreBox is Free Software friendly and %100 supported by “blobless” Linux drivers.

The hardware behind this first LibreBox is based on the Intel 1037U Dual Core CPU. I’m not sure what firmware the LibreBox uses. I presume stock BIOS, not coreboot or UEFI.

Again, I don’t know what LibreTrend is doing with their firmware. Most Linux OEMs are merely taking commodity hardware made for Windows PCs, with stock BIOS, many blobs, fairly insecure compared to UEFI. (Novena is an exception, they’ve crowdsourced new Open Hardware development, and don’t use BIOS. Purism may also be exceptional, but I’ve yet to see specifics of what firmware they’re using.) Most other Linux OEMs are not exceptional w/r/t firmware, and could be be improved by using Intel FSP and coreboot, something that Sage Engineering, an open source BIOS vendor, does. That’d be more Open Source firmware (mostly Free Software-based) and fewer blobs than the default BIOS, which their Linux user audience would presumably prefer. Or they could ship a UEFI and get the additional security that Secure Boot brings to the OS; to help with their Linux user audience further, they could remove the Microsoft certs, something they could do as an OEM, or if they worked with their BIOS vendor. Intel and SuSE showed how to have a Microsoft key-free Linux system back at IDF 2013, yet AFAIK no OEM is selling hardware like this to the Linux community. Most Linux OEMs need to improve the firmware of their products.

I’m happy to see LibreTrend selling hardware with Free Software pre-installed, focusing on blobs at the Linux driver level. I hope they start building Open Hardware and use something beyond COTS BIOS, in future models, and also focus on blobs at the firmware level.

More Information:
http://www.libretrend.com/en/hardware
https://ubuntu-mate.org/blog/ubuntu-mate-hardware-partnership-with-libretrend/
http://www.phoronix.com/scan.php?page=news_item&px=Ubuntu-Mate-Libre-Hardware