Toshiba adds security features to firmware

Toshiba has added firmware-level security to their Mobile Zero Client:

[…]How Toshiba Mobile Zero Client works
* Power on: User powers on the device, which connects to pre-configured LAN or Wi-Fi
* Boot permission: Device requests boot permission from Toshiba Boot Control Service*
* Big Core download: When boot permission is granted, your unique, secure, Big Core package is encrypted, downloaded and unpacked in the RAM
* Ready to go: Your Big Core, with Linux and the VDI client, is executed – establishing its connection to your VDI server

[…]Beyond supporting the storage of data securely away from the device, TMZC can provide added protection through Toshiba’s uniquely developed BIOS, which is designed and built in–house to help remove the risk of third-party interference.[…] We’re one of the only manufacturers that creates our own BIOS and UEFI’s.[…]

http://us.toshiba.com/solutions/tmzc

http://www.businesswire.com/news/home/20170613005346/en/Toshiba-Expands-Portfolio-Security-Solutions-Addition-Mobile

Mike on Windows Config Mgr and Secure Boot

Mike Terrill has 2 blog posts on Windows Configuration Manager and UEFI Secure Boot:

BIOS and Secure Boot State Detection during a Task Sequence
With all of the security issues and malware lately, BIOS to UEFI for Windows 10 deployments is becoming a pretty hot topic (unless you have been living under a rock, UEFI is required for a lot of the advanced security functions in Windows 10). In addition, with the Windows 10 Creators Update, Microsoft has introduced a new utility called MBR2GPT that makes the move to UEFI a non-destructive process. If you have already started deploying Windows 10 UEFI devices, it can be tricky to determine what state these devices are in during a running Task Sequence. The Configuration Manager Team introduced a new class called SMS_Firmware and inventory property called UEFI that helps determine which computers are running in UEFI in Current Branch 1702. This can be used to build queries for targeting and reports, but it would be nice to handle this plus Secure Boot state (and CSM) during a running Task Sequence. We do have the Task Sequence variable called _SMSTSBootUEFI that we will use, but we need to determine the exact configuration in order to execute the correct steps.[…]

BIOS and Secure Boot State Detection during a Task Sequence Part 1

BIOS and Secure Boot State Detection during a Task Sequence Part 2

 

PNP-ID: Plug and Play Vendor ID tool/library

PNP-ID: given a PNP (Plug and Play) industry-unique Vendor ID, return the Vendor name. This is C code that, given a PNP (Plug and Play) industry-unique Vendor ID, returns the Vendor name. This file contains a script, update.sh to automatically download the PNP ID REGISTRY from the UEFI Forum body, and generate and compile a C program and a test binary. The C program uses a binary search to efficiently resolve a PNP Vendor ID to the Vendor name.

https://github.com/golightlyb/PNP-ID

 

Green Threads for UEFI

Green Threads for UEFI: This project is a an alpha version of “green” threads for UEFI. It’s not really like Linux green threads as there is no distinction between user space and kernel space but the different threads are running on the same core

This C-based project has a bit of Intel-centric assembly language code.

Wikipedia defines “Green Threads” as: “threads that are scheduled by a runtime library or virtual machine (VM) instead of natively by the underlying operating system. Green threads emulate multithreaded environments without relying on any native OS capabilities, and they are managed in user space instead of kernel space, enabling them to work in environments that do not have native thread support.”

https://github.com/Openwide-Ingenierie/GreenThreads-UEFI

https://en.wikipedia.org/wiki/Green_threads

William Leara on using the UDK

William Leara of Dell has a new blog post, with a tutorial on writing a UEFI hello-world app using the UDK.

“Hello World” Quick-Start with UDK2015

The objective of this post is to explain how to get started with UEFI development by getting the UDK2015 development environment up and running, creating a Hello, World example program, and running it in the UEFI shell. Once you can get a simple application built and running in a UEFI Shell, you can begin extending it to greater and greater sophistication![…]

http://www.basicinputoutput.com/2017/06/hello-world-quick-start-with-udk2015.html

ARM joins UEFI Forum Board

The UEFI Forum issued a press release today, about ARM joining the board.

UEFI Forum Appoints ARM to Board of Directors Fortifying Its Commitment to Firmware Innovation

ARM Strengthens Its Long-Standing Presence and Contributions to the UEFI Ecosystem
June 06, 2017 11:00 AM Eastern Daylight Time

BEAVERTON, Ore.–(BUSINESS WIRE)–The UEFI Forum, a non-profit industry standards body that champions firmware advancement through industry collaboration and advocacy of firmware technology standards, announced today that ARM has been appointed to the UEFI Forum Board of Directors.[…]

http://www.businesswire.com/news/home/20170606005502/en/UEFI-Forum-Appoints-ARM-Board-Directors-Fortifying

http://www.uefi.org/node/3715

 

 

 

UEFI updates specs

The UEFI Forum has updated their specs.

UEFI Spec v2.7

Click to access UEFI_Spec_2_7.pdf

PI v1.6

Click to access PI_Spec_1_6.pdf

ACPI v6.2

Click to access ACPI_6_2.pdf

SCT v2.5A
http://www.uefi.org/testtools

http://uefi.org/specsandtesttools
http://uefi.org/specifications

automated-efi-fw-update

automattically update server and adapter firmware using efi shell

This Updatepack automates and simplifies the update process of Intel Servers and Adapters. […] Supported Devices:

Intel S2600WT Server Board Family
Intel RMS3JC080 RAID Controller
Intel RMS3CC080 RAID Controller
Intel RES3TV360 SAS Expander
QLogic BR1860-2 Converged Network Adapter
Lenovo N2225 SAS Host Bus Adapter

https://github.com/thost96/automated-efi-fw-update

Careful, this Github project includes some binary-only *.EFI files, no source code included.

NIST SP 800-193: Platform Firmware Resiliency Guidelines

I thought I got all the appropriate NIST announcements, but missed this, found it in Vincent’s recent blog post:

http://vzimmer.blogspot.com/2017/05/uefi-and-security-postings.html

Very exciting to see this NIST document!

Draft NIST Special Publication 800-193
Platform Firmware Resiliency Guidelines
Andrew Regenscheid

This document provides technical guidelines and recommendations supporting resiliency of platform firmware and data against potentially destructive attacks. The platform is a collection of fundamental hardware and firmware components needed to boot and operate a system. A successful attack on platform firmware could render a system inoperable, perhaps permanently or requiring reprogramming by the original manufacturer, resulting in significant disruptions to users. The technical guidelines in this document promote resiliency in the platform by describing security mechanisms for protecting the platform against unauthorized changes, detecting unauthorized changes that occur, and recovery from attacks rapidly and securely. Implementers, including Original Equipment Manufacturers (OEMs) and component/device suppliers, can use these guidelines to build stronger security mechanisms into platforms. System administrators, security professionals, and users can use this document to guide procurement strategies and priorities for future systems.

http://csrc.nist.gov/publications/PubsDrafts.html#SP-800-193

 

Intel ATR releases UEFI firmware training materials!

Good news: the Intel Advanced Threat Research (ATR) team has release some of their UEFI security training materials!

This repository contains materials for a hands-on training ‘Security of BIOS/UEFI System Firmware from Attacker and Defender Perspectives’. A variety of attacks targeting system firmware have been discussed publicly, drawing attention to the pre-boot and firmware components of the platform such as BIOS and SMM, OS loaders and secure booting. This training will detail and organize objectives, attack vectors, vulnerabilities and exploits against various types of system firmware such as legacy BIOS, SMI handlers and UEFI based firmware, mitigations as well as tools and methods available to analyze security of such firmware components. It will also detail protections available in hardware and in firmware such as Secure Boot implemented by modern operating systems against bootkits. The training includes theoretical material describing a structured approach to system firmware security analysis and mitigations as well as many hands-on exercises to test system firmware for vulnerabilities. After the training you should have basic understanding of platform hardware components and various types of system firmware, security objectives and attacks against system firmware, mitigations available in hardware and firmware. You should be able to apply this knowledge in practice to identify vulnerabilities in BIOS and perform forensic analysis of the firmware.

0 Introduction to Firmware Security
1 BIOS and UEFI Firmware Fundamentals
2 Bootkits and UEFI Secure Boot
3 Hands-On Platform Hardware and Firmware
4 System Firmware Attack Vectors
5 Hands-On EFI Environment
6 Mitigations
7 System Firmware Forensics
N Miscellaneous Materials

https://github.com/advanced-threat-research/firmware-security-training

UEFI-SecureBoot-SignTool

Aneesh Neelam has written UEFI-SecureBoot-SignTool, a script to sign external Linux kernel modules for UEFI Secure Boot.


UEFI Secure Boot sign tool

The default signed Linux kernel on Ubuntu (>=16.04.x), Fedora (>=18) and perhaps on other distributions as well, won’t load unsigned external kernel modules if Secure Boot is enabled on UEFI systems. Hence, any external kernel modules like the proprietary Nvidia kernel driver, Oracle VM VirtualBox’s host/guest kernel driver etc. won’t work. External kernel modules must be signed for UEFI Secure Boot using a Machine Owner Key (MOK). You can use the UEFI Secure Boot Sign Tool to sign kernel modules. This is useful if you can’t or don’t wish to disable Secure Boot on your UEFI-enabled system.[…]

https://github.com/aneesh-neelam/UEFI-SecureBoot-SignTool

 

 

Secure Boot BOF at DebConf17

Helen Koike of Collabora has proposed a BOF on UEFI Secure Boot at DebConf17, this August:

DebConf17 – BoF proposal to discuss secure boot
I want to send a BoF proposal to DebConf17 so we can meet there and discuss about secure boot. I would like to know if you are interested in attending and also which topics you suggest for discussion. I would appreciate if you could put your name and suggestions in this form in case you are interested https://goo.gl/forms/lHoEibY1H6FmSHSJ2 , or just reply to this email thread.

For full message, see the debian-efi mailing list archives.

https://lists.debian.org/debian-efi/2017/05/threads.html

https://docs.google.com/forms/d/e/1FAIpQLSdtHYNy9212iXP26tkjbb6XvgVSMjJzn2DYoAilFT1l89vemw/viewform?c=0&w=1

https://debconf17.debconf.org/

 

 

Linux kernel EGP_PGT_DUMP build option

Sai Praneeth Prakhya of Intel submitted V2 of an Intel UEFI diagnostic patch for the Linux kernel, the new version adds x86 support.

[PATCH V2] x86/efi: Add EFI_PGT_DUMP support for x86_32, kexec
EFI_PGT_DUMP, as the name suggests dumps efi page tables to dmesg during kernel boot. This feature is very useful while debugging page faults/null pointer dereferences to efi related addresses. Presently, this feature is limited only to x86_64, so let’s extend it to other efi configurations like kexec kernel, efi=old_map and to x86_32 as well. This doesn’t effect normal boot path because this config option should be used only for debug purposes.

Changes since v1:
1. Call efi_dump_pagetable() only once from efi_enter_virtual_mode() – as suggested by Boris

For more info, see the patch on the linux-(kernel,efi) lists.