Nikolaj’s UEFI SecureBoot tutorial

CodeRush has a new tutorial on UEFI SecureBoot:
Taming UEFI SecureBoot tutorial

[…] let’s talk about how to make a UEFI SecureBoot not work for the benefit of Microsoft, as it is often set at default, and for the good of us. If you’re wondering how to generate their own your own keys for SecureBoot how to install them instead of the standard (or with them), you sign your favorite EFI-boot, how to prevent loading of unsigned or signed other people’s key code, it looks like the interface to configure SecureBoot at AMI, Insyde and Phoenix, […]

It is in Russian, use a translation tool if you can’t read Russian (like me). The article has multiple examples and screenshots of multiple UEFI implementations, and includes some UEFI links at the end that I’ve never seen before, exciting!

http://habrahabr.ru/post/273497/It’s/

http://translate.google.com/translate?hl=en&sl=ru&tl=en&u=http%3A%2F%2Fhabrahabr.ru%2Fpost%2F273497%2FIt%27s%2F&sandbox=1

Guido Stepken on Linux UEFI TPM 2.0 backdoors

https://twitter.com/SecNewsBot/status/677681956176404480

Guido Stepken has a Google+ post from September (which I didn’t notice back then), and the SecNewsBot on Twitter just posted this like it is news. Well, it is news to me. 😦

Linux UEFI TPM 2.0 security impacts:
The “security chain” begins with one or more TPM 2.0 “Endorsement Keys” (EK), that are stored on the motherboard and that cannot be overwritten without “allowance” by either the owner (hardware manufacturer) or somebody, that is “higher” in key hierarchy, such as Microsoft or U.S. government authorities. Key Exchange Keys (KEK) establish a trust relationship between the operating system and the platform firmware. Each operating system (and potentially each 3rd party application, that needs to communicate with platform firmware) enrolls a public key (KEKpub) into the platform firmware. When your hardware comes “Windows Certified”, the “Endorsement Key” already is initialized, is signed by Microsoft and U.S. authorities. “Windows certified” here automatically means “NSA backdoor” included and activated in all encryption modules. Hardware encryption on newer INTEL Xeon machines, at boot, load those key rings from UEFI tables into processor buffer. From then on, the CPU hardware encrypts everything with Microsoft and U.S. authorities keys being enclosed in the key ring, independent of used operating system! […]

Full article:

https://plus.google.com/+GuidoStepken/posts/XZsgDcuairt

LUV-live 2.0-RC4 released

Ricardo Neri of Intel announced Linux UEFI Validation (LUV) v2.0-rc4 release, with lots of changes, new versions of CHIPSEC, BITS, FWTS, and multiple UEFI improvements in LUV. IMO, one of the most important features it that LUV-live’s CHIPSEC should properly log results now! Excerpts from Ricardo’s announcement:

This release touches many areas. Here are some highlights:

Naresh Bhat implemented changes to build from Linus’ tree when building LUV for ARM. While doing this, he got rid of the leg-kernel recipe. Now the kernel is built from linux-yocto-efi-test for all architectures. Also, he took the opportunity to remove some of the LUV-specific changes we had in the meta layer (i.e., our genericarmv8 machine). It always good to restrict ourselves to the meta-luv layer, unless we plan to upstream to the Yocto Project. Now LUV for aarch64 is built using qemuarm64.

It was reported that CHIPSEC was not running correctly in LUV due to missing configuration files and Python modules. This release includes a major rework of CHIPSEC integration into LUV. It ran correctly on all the systems in which we tested. Also, we bumped to v1.2.2; the CHIPSEC latest release.

This release includes new functionality to build BITS from its source rather than just deploying its binaries. BITS is a challenging piece of software when it comes to integration into a bitbake recipe. The build process was broken into several steps. This work help for future work to customize BITS for other CPU architectures and netboot.

The UEFI specification v2.5 includes a Properties Table for the memory map. Under this feature, it is possible to split into separate memory sections the code and data regions of the PE/COFF image. Unfortunately, kernels previous to v4.3 crash if this features is enabled. We have backported a fix pushed to Linux v4.3. We will be bumping the kernel for x86 to 4.3 in our next release.

The EFI stub feature in the kernel allows to run the kernel as an EFI application. Also, it allows the kernel to parse the memory map directly from the firmware rather than taking the map from the bootloader. This is clearly advantageous in case of bugs in the bootloader.

Now that LUV support storing the results of multiple bots, it may happen that disk runs out of space. Gayatri Kammela made updates to increase the size of the results partition and issue a warning when available space runs below 2MB.

Finally, keeping up with the latest changes in the Yocto Project has paid off handsomely. This release is based on Jethro, the latest version of the Yocto Project. Rebasing to this new version as done with very little effort. In the LUV tree you can find the jethro and jethro-next branches; the bases of this release. The fido and fido-next branches are still maintained.

We have bumped the following test suite versions:

 *FTWS is now V15.12.00
 *CHIPSEC is now v1.2.2
 *BITS is 2005

Time to update your LUV-live images! It is a Release Candidate, so please help the LUV team by testing it out and pointing out any issues on the LUV mailing list. This version of CHIPSEC includes VMM tests, so time to test LUV-luv in your virtual machines, not just on bare-metal boxes.

Many people contributed to this release, including: Ricardo Neri, Naresh Bhat, Darren Bilby, Megha Dey, Gayatri Kammela, John Loucaides, Sai Praneeth Prakhya, and Thiebaud Weksteen. It was nice to see the LUV and CHIPSEC teams work together in this release!

More information:
https://lists.01.org/pipermail/luv/2015-December/000745.html
https://download.01.org/linux-uefi-validation/v2.0/luv-live-v2.0-rc4.tar.bz2
https://download.01.org/linux-uefi-validation/v2.0/sha256_sums.asc

https://01.org/linux-uefi-validation/

FDBG: AMD64 UEFI debugger

While searching for information about FASM for that last blog post, I also noticed this:

http://fdbg.x86asm.net/

“fdbg for AMD64 is assembler level debugger for user-mode (ring3) binary applications, running in long mode (64-bit) – Windows and Linux versions. Version for UEFI x64 is also available.

Supported platforms:

  • Windows XP x64, Windows 2003 server x64, Vista x64, Windows 2008 server x64, Windows 7 x64
  • Linux x64
  • UEFI x64

Windows Version is GUI based.

Linux version is command line based (console) and doesn’t need any library to run so it doesn’t matter what Linux distribution you use.

UEFI version is command line based.

fdbg project was started to help in debugging programs written in assembler to everybody who feels the power of assembler

 

  • it is written in Flat Assembler and source files are included
  • its syntax is similar to FASM
  • it supports debug symbols and you can find some tricks in included help how to debug without symbols
  • it is suitable for everybody who tries to create his/her first program written in assembler
  • it has some features and power for experienced users too
  • it is very small

 

I haven’t tried it yet,  but this looks interesting…

UEFI programming in Flat Assembler (FASM)

FASM is the Flat Assembler. There’s a new Github project with some FASM-based assembly hello-world samples for UEFI. UEFI’s EDK-II generall prefers C over assembly, and has some code to help replace the need for assembly: I have some notes on that somewhere, I was going to write a blog on that someday. And I thought that EDK-II prefers NASM as their assembler, so this FASM-based, Intel 32-bit assembly-based UEFI sample code is interesting. The x86asm.net article on UEFI programming also has examples of FASM-based UEFI programming.

https://github.com/eszkadev/UEFI-32bit-asm-examples

http://flatassembler.net/

http://x86asm.net/articles/uefi-programming-first-steps/

AMI adds NFC to Aptio V

AMI has announced support of NFC (near field communication) support for Aptio V, their UEFI firmware solution. Excerpt from press release on the features added to adding to secure NFC:

“With the increasing use of NFC technology, American Megatrends Inc. is now developing NFC support for its flagship Aptio(R) V UEFI BIOS firmware to further security measures. Alongside this support, various features that incorporate NFC technology will be available to users. One of the features, the NFC BIOS Authentication, acts as a replacement to standard password authentication and gives users the ability to authenticate their BIOS using various methods and devices. Authentication can take place using an NFC-enabled cell phone, tablet or identification badge. Administrator and user privileges are based on badge identifications. When an NFC device is detected, the NFC device can be configured to initiate BIOS recovery and specific device booting. Other features will include a single sign on to pass information to the OS, diagnostic and debugging information, and NFC-based Bluetooth pairing.”

http://ami.com/news/press-releases/?PressReleaseID=347&/American%20Megatrends%20Announces%20Development%20of%20NFC%20Support%20for%20Aptio%C2%AE%20V/

I presume this means that Tianocore has no NFC support. (I just realize I’ve never checked…)

EDK-II Build Data Viewer

William Leara has a new blog post on Intel’s EDK-II Build Data Viewer tool; it is a detailed post with multiple screenshots and images:

http://www.basicinputoutput.com/2015/12/the-edkii-build-data-viewer.html

Wow, I missed this tool from Intel when it first came out, so I’m very glad for this post! Note this source project is hosted on 01.org, not tianocore.org.

Unfortunately, it sounds like the tool may be difficult to use:

The EDKII Build Data Viewer is beautifully designed.  The documentation is top notch.  It provides a wealth of information in one place that would be time-consuming to discover independently.  Unfortunately I was not able to get it to run on the production BIOS source trees I have available to me, but hopefully you have better luck.”

If anyone gets it working, please leave a comment with a pointer to more info.

https://github.com/01org/edkiibuilddataviewer

Brian on Secure Boot -vs- Nemesis

Brian Richardson of Intel wrote a new blog on the recent Nemesis malware:

(Nemesis targets BIOS-centric MBR not UEFI-centric GPT partititions.)

http://blogs.intel.com/evangelists/2015/12/08/nemesis-meet-uefi-secure-boot/

bus1’s boot-efi project

Bus1’s boot-efi, “UEFI Boot Manager”, is a new Github project, consisting of two components:


bootx64.efi: Boot Manager

 – searches EFI binaries in (ESP)/EFI/bus1/*.efi
 – executes the latest release version
 – if a key is pressed during bootup, a menu is drawn showing all found binaries
 – built-in command line editor

stubx64.efi: Boot Code Stub
 – executes the embedded PE-sections which contain the kernel, initrd,
   kernel cmdline, release string
 – shows the splash screen from the embedded PE section

I’m not sure what Bus1 is. Their motto: “Somewhere, something incredible is waiting to be known.” Besides the above boot manager, they also have a few other new projects, including another UEFI one called Build, “Build UEFI Disk”.

More information:

https://github.com/bus1/build
https://github.com/bus1/boot-efi

HPE Synergy’s Unified API for UEFI and Redfish

HP, now called HPE, has enhanced firmware/pre-OS support in their new servers, with their Synergy product having a “Unified API” that addresses Pre-OS technologies like Redfish and UEFI. They have a new RESTful API, and a tool for using that API. I am unclear, I think they are related. (I don’t have access to the latest HP hardware to clarify.

More information:
http://www.computerworld.com/article/3010261/servers/hpes-synergy-is-a-new-type-of-composable-infrastructure.html
http://www.theregister.co.uk/2015/12/01/hpe_synergy/
http://www.pcworld.com/article/3010526/hpes-synergy-is-a-new-type-of-composable-infrastructure.html

http://www8.hp.com/us/en/products/servers/proliant/restful-interface-tool.html
https://github.com/HewlettPackard/PowerShell-ProLiant-SDK
https://github.com/HewlettPackard/python-proliant-sdk
http://www8.hp.com/us/en/products/server-software/product-detail.html?oid=7630408
http://www8.hp.com/us/en/products/server-software/product-detail.html?oid=6935826

Linux and Secure Boot HOW-TO

Greig Paul has an article in Linux Journal, a new Security HOW-TO on UEFI Secure Boot.

Take Control of Your PC with UEFI Secure Boot

[..] This article focuses on a single useful but typically overlooked feature of UEFI: secure boot. Often maligned, you’ve probably encountered UEFI secure boot only when you disabled it during initial setup of your computer. Indeed, the introduction of secure boot was mired with controversy over Microsoft being in charge of signing third-party operating system code that would boot under a secure boot environment. In this article, we explore the basics of secure boot and how to take control of it. We describe how to install your own keys and sign your own binaries with those keys. We also show how you can build a single standalone GRUB EFI binary, which will protect your system from tampering, such as cold-boot attacks. Finally, we show how full disk encryption can be used to protect the entire hard disk, including the kernel image (which ordinarily needs to be stored unencrypted). […]

Full article:

http://www.linuxjournal.com/content/take-control-your-pc-uefi-secure-boot

Nikolaj’s ZeroNights presentation available

Congratulations to Nikolaj on his first presentation! His presentation is now available!

The section on Protections is especially worth reading!

https://twitter.com/NikolajSchlej/status/669902996046761984

https://github.com/NikolajSchlej/ZeroNights2015

Click to access FixItYourself_Schlej.pdf

UEFI updated to IPMI v2.0

Daocheng Bu of Intel has added IPMI 2.0 definitions to the EDK2 project.

MdePkg/Include/IndustryStandard/Ipmi.h             |  26 +
…/IndustryStandard/IpmiNetFnAppDefinitions.h     | 614 +++++++++++++++++++++
…/IndustryStandard/IpmiNetFnBridgeDefinitions.h  | 238 ++++++++
…/IndustryStandard/IpmiNetFnChassisDefinitions.h | 294 ++++++++++
…/IpmiNetFnFirmwareDefinitions.h                 |  26 +
…/IpmiNetFnGroupExtDefinitions.h                 |  26 +
…/IpmiNetFnSensorEventDefinitions.h              |  44 ++
…/IndustryStandard/IpmiNetFnStorageDefinitions.h | 514 +++++++++++++++++
…/IpmiNetFnTransportDefinitions.h                | 531 ++++++++++++++++++
9 files changed, 2313 insertions(+)

For more information see the edk2-devel posts (or look at the current EDK2 trunk in the above files):
https://lists.01.org/mailman/listinfo/edk2-devel

Updated UEFI training from Intel SSG

It appears there are a few new files on Tianocore.org, beyond latest EDK-II trunk source changes.

Intel has a multi-day training course for (presumably) Intel employees and partners. Intel releases the presentations and lab workshop materials for the course for public access, as part of the Tianocore project, and updates it periodically. And they recently updated it again, grab the 2 files at the top of the list, with recent dates. I just downloaded it, unsure what is new in the labs yet…
http://sourceforge.net/projects/edk2/files/Training/TrainingMaterial/

Also see updated versions of the online presentations here:
http://sourceforge.net/projects/edk2/files/Training/
https://github.com/tianocore/tianocore.github.io/wiki/UEFI%20EDKII%20Learning%20Dev

I think this page may be slightly out-of-date for the moment:
http://firmware.intel.com/learn/uefi/uefi-training-materials

As for other updates to tianocore/EDK2, the EDK-II C Coding Conventions have been revised:
http://sourceforge.net/projects/edk2/files/Specifications/

I usually find it is best to find fresh Tianocore files by looking at these two locations first:
https://github.com/tianocore
http://sourceforge.net/projects/edk2/files/

ISSA Ottawa: intro to UEFI and why you should care

If you are in the Ottowa area, the ISSA event in 2 days sounds interesting:

An Introduction to UEFI and Why We Should Care

An introduction to UEFI (Unified Extensible Framework Interface) and the supported security controls framework. We will discuss how these UEFI security controls may be bypassed or where firmware implementations have failed, with the goal of compromising the integrity of the boot process and the running Operating System.

Speaker:  Mr. Sues, CEO of Rigel Kent Security, Cryptid Labs and co-CEO of Invariant Security is an experienced Penetration Tester, Vulnerability Researcher and Security Trainer with an extensive background in both operational penetration testing and the identification of new vulnerabilities in applications and operating systems. Mr. Sues develops tools and exploits, specializing in the development buffer overflow technology for use in assessing client systems. In doing so, he has reverse engineered many commercial and custom UNIX and Windows-based applications, protocols and Operating Systems to locate and analyze vulnerabilities or understand the software’s operation. As well, he has evaluated many vendor products, commercial and proprietary encryption algorithms, operating systems, network services, SANs, routers, and firewalls such as Checkpoint and CISCO PIX/ASA firewalls and has performed local host vulnerability assessments of firewalls, routers/switches, Windows Servers and Solaris/UNIX/Linux systems. Mr. Sues is also co-founder of the COUNTERMEASURE series of security conferences and training events held in Ottawa, Canada with the most recent, COUNTERMEASURE 2015, held November 16-20, 2015.

http://events.r20.constantcontact.com/register/event?llr=i4mkfneab&oeidk=a07ebs3188hc4ff8736