There’s a bit more to be gleaned from reading the above two twitter threads.
Tag: UEFI
More info on Microsoft BIOS to UEFI feature
Earlier I saw some brief information about some “BIOS to UEFI” feature that Microsoft was adding to some product of theirs, but had no idea what it was about. Here is a bit more information on the System Center feature:
“Improvements for BIOS to UEFI conversion
You can now customize an operating system deployment task sequence with a new variable, TSUEFIDrive, so that the Restart Computer step will prepare a FAT32 partition on the hard drive for transition to UEFI. The following procedure provides an example of how you can create task sequence steps to prepare the hard drive for the BIOS to UEFI conversion.”
https://technet.microsoft.com/library/mt772349(TechNet.10).aspx#Improvements-for-BIOS-to-UEFI-conversion
Linaro Connect
ARM’s Linaro Connect is happening. Click on their web page for live streaming.
In addition to all of the ARM topics, Brian Richardson, an Intel evangelist will be speaking about UEFI at this event. 🙂
UEFI firmware patch for VMware workstation
The earlier post on this was when the project was a new project with no code. They have code now, which consists of a few shell scripts and a patch to linux/driver.c. Presume this is unofficial. 🙂
“This is a program to patch VMware Workstation 12 kernel modules and to sign them using a X.509 key and enrolling the key in the system UEFI firmware.”
https://github.com/hashhar/vmware-module-patch
Intel Firmware Engine 2.1.1 for Windows released
another UEFI library in Rust
No docs yet, it’s about a week old.
Look at the Rust tags for older posts to some other Rust UEFI code.
https://github.com/vlad9486/uefi
https://www.rust-lang.org/
Update on Intel SMM updates
Regarding this:
Intel has revised it’s advisory with new dates. September 27th is the new date.
https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00056&languageid=en-fr
Microsoft UEFI unit tests!
Thanks to Microsoft for open sourcing some UEFI unit test harness code!!!
https://github.com/Microsoft/MsUEFI-Test/tree/master/MsUnitTestPkg
CHIPSEC adds capsule parsing and blacklists ThinkPwn
CHIPSEC has had a few significant updates recently:
https://github.com/chipsec/chipsec/pull/73
https://github.com/chipsec/chipsec/pull/89
[…] It detects EFI binaries which have the following attributes:
1. GUID A56897A1-A77F-4600-84DB-22B0A801FA9A string of vulnerable UEFI SmmRuntime protocol within the contents of EFI binaries
2. Two names (UI strings) ‘SystemSmmRuntimeRt.efi’ and ‘SmmRuntime’ and two GUIDs 7C79AC8C-5E6C-4E3D-BA6F-C260EE7C172E and A56897A1-A77F-4600-84DB-22B0A801FA9A of vulnerable EFI binaries found in different systems[…]
Peter Jones on Secure Boot failures and mitigations
I just now came across a blog post written by Peter Jones from LAST MONTH on that “Microsoft Secure Boot Golden Key” news reports that is worth reading. Peter owns the Linux shim, so he knows a bit about UEFI’s boot process.
https://blog.uncooperative.org/blog/2016/08/18/secure-boot-failures-and-mitigation/
Especially because I’ve had nearly nothing useful in this blog on this post:
Also note other articles in Peter’s blog: he makes regular canary posts about the state of his Shim code. I wish all of the boot/firmware code required all contributes to have canaries!
New UEFI Capsule Update and Recovery sample
Jiewen Yao of Intel checked in a *45-part* patch to the Tianocore project, adding a new UEFi Capsule sample and documentation!
This series patch provides sample on how to do signed capsule update and recovery in EDKII. The feature includes:
1) Define EDKII signed system BIOS capsule format.
2) Provide EDKII signed system BIOS update sample.
3) Provide EDKII signed recovery sample.
4) Provide Microcode update sample for X86 system.
5) Update Quark to use new capsule/recovery solution.
6) Update Vlv2(MinnowMax) to use new capsule/recovery solution.
The signed capsule/recovery solution is in MdeModulePkg. The capsule in IntelFrameworkModulePkg is deprecated. The Microcode update solution is in UefiCpuPkg.
124 files changed, 17848 insertions(+), 384 deletions(-)
For more info, see the full patch:
https://lists.01.org/mailman/listinfo/edk2-devel
.
UEFI plugfest in Seattle next week
(Next week’s plugfest will be the same week Intel is supposed to release their SMM updates.)
https://twitter.com/Intel_UEFI/status/775733237331013632
https://twitter.com/Intel_UEFI/status/775394642409902080
I’ll be attending this event, maybe I’ll see a few of you there. 🙂
Lindholm on UEFI driver development
Leif Lindholm has a new blog post, which appears to be the first in a series, on UEFi development. As most UEFI-centric blog posts are often Intel-centric, I’m looking forward to seeing some ARM-centric UEFI topics!
UEFI Driver Development – Part 1
One of the key features of UEFI is that the specification and the APIs/ABIs it guarantees provides the ability to produce portable applications, drivers and libraries (in the form of protocols). On the simpler side, by letting you compile the driver once for each architecture – and on the more space age side by letting you build a single driver that works across all architectures (using EFI Byte Code). The extra magic comes in the form of Option ROM support, which lets plug-in PCI cards keep a driver onboard, informing UEFI to load it on boot. (Any jokes about Forth drivers for Open Firmware go here.) So, having never actually written a UEFI driver from scratch, and most of the drivers I have come across having really been platform drivers, I figured that would be a good start to write a standalone driver from scratch. And the outcome is this slightly hands-on blog post series. This part covers:
* creating a new driver from scratch
* building it as a standalone driver
* loading it from the UEFI Shell
* having it detect the presence of a device it recognizes
* unloading it from the UEFI Shell
[…]
UEFI EDK2 FDF V1.27 draft spec available
Laurie Jarlstrom of Intel announced the latest UEFI FDF spec: V1.27 Draft for Review.
“Please Review By EOW”.
I think I already saw an issue show up on the public EDK2 bug database.
EDK II FDF File Spec v1.27 DRAFT for Review
Update Sept 2016 (DRAFT)
This document describes the EDK II Flash Description (FDF) file format. This format was designed to support new build requirements of building EDK and EDK II modules within the EDK II build infrastructure. The EDK II Build Infrastructure supports generation of current Unified EFI, Inc. (UEFI 2.6 and PI 1.4) compliant binary images. The FDF file is used to describe the content and layout of binary images. Binary images described in this file may be any combination of boot images, capsule images or PCI Options ROMs.
https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Specifications
SPYRUS secure USB drives in some Microsoft Surface devices
Recently SPYRUS, Inc. announced the integration of their NIST 140-2 Level 3 secure USB 3.0 drive family with Microsoft Surface Pro devices.
“SPYRUS is currently the only manufacturer of hardware encrypted Windows To Go products that have successfully integrated support with the Microsoft Surface Pro family of tablets. The unique feature set, to include provisioning support to boot the Windows To Go in UEFI Secure Boot mode, in conjunction with FIPS 140-2 Level 3 certification sets a new standard for security features and performance,” said Tom Dickens, SPYRUS COO. “Use cases for these smart drives also dovetail perfectly with the rapidly emerging requirements for collaboration, secure data storage, secure mobile computing, and secure devices with auditable cybersecurity.”
http://www.spyrus.com/windows-to-go-live-drives and http://www.spyrus.com/encrypting-usb-storage/
http://www.spyrus.com/spyrus-announces-integration-of-windows-to-go-and-p-3x-product-lines-with-microsoft-surface-pro-3-and-4/
FWTS 16.09.00 released
Alex Hung of Canonical announced the latest release of FWTS, the FirmWare Test Suite, on the fwts-announce and other lists.
New Features include:
* lib: acpi: add supports for WPBT
* acpi: wpbt: add ACPI WPBT test
* lib: acpi: add supports for DRTM
* acpi: drtm: add ACPI DRTM test
* lib: fwts_guid: add a compare function
* acpi: nfit: check fields equals 0 for Virtual CD and Disk
* opal: mtd: Add OPAL MTD Validation
* acpi: ACPI Platform check updates
* acpi: fadt: Remove HEADLESS check on reduced hardware
* pci: aspm: Add segment support
* ACPICA: Update to version 20160831
See the full announcement for list of bugfixes.
http://fwts.ubuntu.com/release/fwts-V16.09.00.tar.gz
https://launchpad.net/~firmware-testing-team/+archive/ubuntu/ppa-fwts-stable
https://wiki.ubuntu.com/FirmwareTestSuite/ReleaseNotes/16.09.00
https://launchpad.net/ubuntu/+source/fwts
New UEFI RNG tool
Finnbarr P. Murphy has a new UEFI tool that checks your firmware for RNGs, and it sounds like he’s found some Lenovo Thinkpad errors with it:
[…] Here is a small UEFI shell utility that checks your firmware for available RNGs: […] I built the utility on a 64-bit Fedora 24 platform using GCC and UDK2015. I have not tried building a 32-bit utility nor have I build it using Visual Studio or other development frameworks – so do not be surprised if you have modify either the code or the build recipe in these cases. I tested the utility on a Lenovo T450 using firmware version JBET60WW (1.24) and was surprised to find that the firmware did not appear to support any RNGs as evidenced by the zero RNG algorithm count returned. However, by explicitly, testing for the default RNG if the count was zero, it was possible to determine that the T450 did in fact at least support the default RNG. Perhaps, I am not parsing the UEFI specification correctly but I would expect the RNG count returned by GetInfo to include the default RNG. Interestingly, when I build and load the UDK2015 test RNG DXE driver which contains a reference counter mode DRBG (Deterministic Random Bit Generator) conforming to NIST SP 800-90a, the algorithm count returned by GetInfo jumps to 2. This leads me to suspect that their is a bug in the firmware w.r.t. to the RNG protocol implementation. Please let me know if I am incorrect in my assumptions or observations.
http://blog.fpmurphy.com/2016/08/rng-protocol-error-in-lenovo-thinkpad-firmware.html
Update on Intel SMM vulnerability
Intel SMM EoP mitigations due Sep-19
https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00056&languageid=en-fr
Intel has a security advisory about SMM Elevation of Privilege vulnerability on multiple Intel product. It appears they have an estimated release for this: “Estimated Sept. 19th”
Severity rating: Important
Intel is releasing mitigations for a privilege escalation issue. This issue affects the UEFI BIOS of select Intel Products. The issue identified is a method that enables malicious code to gain access to System Management Mode (SMM). A malicious attacker with local administrative access can leverage the vulnerable function to gain access to System Management Mode (SMM) and take full control of the platform. Intel products that are listed below should apply the update. Other vendors’ products which use the common BIOS function SmmRuntime may be impacted. To find out whether a product you have may be vulnerable to this issue, please contact your system supplier. Intel highly recommends applying the mitigations. For Intel branded products where a mitigation is still pending, we recommend following good security practices including running with least privilege and keeping security software and operating systems up to date.
The advisory also shows how to use dmidcode on Linux to get the vendor ID:
dmidecode -t 0 | grep Version | awk -F : ‘{ print $2 }’ | sed s/\ //g
dmidecode -t 2 | grep Product | awk -F : ‘{ print $2 }’ | sed s/\ //g
More info:
https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00056&languageid=en-fr
New Intel/UEFI whitepaper: Establishing the Root of Trust
https://twitter.com/Intel_UEFI/status/773597835467956224
Click to access UEFI%20RoT%20white%20paper_Final%208%208%2016%20%28003%29.pdf
Vincent Zimmer and Michael Krau of Intel have written a new whitepaper for the UEFI Forum: “Establishing the root of trust”.
The first step in securing a computing device – from a simple embedded device to a supercomputer and everything in between – is to ensure that it can start up under the following conditions:
– It is operating as expected
– All the firmware needed to run the system is intact
– It has not been tampered with in any way
As described in the first white paper in this series, Understanding the Chain of Trust and Its Vital Role in Keeping Computing Systems Secure, the UEFI specification includes a mechanism for ensuring the integrity and security of firmware (the all-important link between the hardware and the operating system) as a system starts up. This mechanism is called Secure Boot and uses public key cryptography to validate that each piece of firmware has been digitally signed and is therefore unmodified as the system starts up. In a chain of trust, each piece of firmware must be digitally signed before it can start up. Once one piece of code has been validated, it can then validate the next section and so on until the system is fully booted and control handed over to the operating system. But how does that chain get started? While difficult, it would be possible for an attacker to inject malicious attack code of some sort prior to start of the chain of trust to gain low-level and nearly undetectable control over the system. To prevent this, the chain of trust requires a strong foundation. In modern systems, this is known as the root of trust. A root of trust, one that can be counted on to anchor the chain of trust in the face of the most determined attackers, can be established in a number of ways. The most secure approaches use some form of an unchangeable section of hardware to validate the initial keyed signature, but there are a number of effective approaches. Ultimately it comes down to the level of security you’re comfortable with and an understanding of the approach used to establish the root of trust. This white paper looks at several common methods for establishing a root of trust as the basis for the UEFI Secure Boot process. […]
EFI changes for Linux v4.9
Matt Fleming sent a message to Linux Kernel/EFI lists with a set of UEFI-centric patches for Linux 4.9. Excerpting his message:
[…]There’s more work on refactoring EFI code to be architecture independent and the largest number of patches is spent cleaning up the EFI memory map code and allowing drivers on x86 to reserve EFI boot services for all of runtime. The architecture independent quest is going pretty well and it was only a couple of lines to get the esrt driver working on arm64. Other than that there’s some cleanups and fixes, and a merge of the out of tree EFI runtime driver from the FWTS project.
* Refactor the EFI memory map code into architecture neutral files and allow drivers to permanently reserve EFI boot services regions on x86, as well as ARM/arm64 – Matt Fleming
* Add ARM support for the EFI esrt driver – Ard Biesheuvel
* Make the EFI runtime services and efivar API interruptible by swapping spinlocks for semaphores – Sylvain Chouleur
* Provide the EFI identity mapping for kexec which allows kexec to work on SGI/UV platforms with requiring the “noefi” kernel command line parameter – Alex Thorlton
* Add debugfs node to dump EFI page tables on arm64 – Ard Biesheuvel
* Merge the EFI test driver being carried out of tree until now in the FWTS project – Ivan Hu
* Expand the list of flags for classifying EFI regions as “RAM” on arm64 so we align with the UEFI spec – Ard Biesheuvel
* Optimise out the EFI mixed mode if it’s unsupported (CONFIG_X86_32) or disabled (CONFIG_EFI_MIXED=n) and switch the early EFI boot services function table for direct calls, alleviating us from having to maintain the custom function table – Lukas Wunner
* Miscellaneous cleanups and fixes
[…]
git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.git tags/efi-next
Firmware Security 
You must be logged in to post a comment.