More Info on UEFI 2.5 HTTP Boot Implementations

Earlier, I made this blog post on UEFI 2.5’s new HTTP Boot feature. At that time, I was unaware of some details, like if this feature will be implemented in TianoCore, or only in commercial products. HP gave a talk at the Spring UEFI Forum on UEFI 2.5 HTTP Boot (to replace PXE) and DMTF Redfish (to replace IPMI), so I presume some new HP products will have these new features soon, if not already. On the EFI development list, I asked a question about Tianocore and vendor support of UEFI HTTP boot, as well as DMTF Redfish, and got 2 replies, one from Intel and one from HP.

Ye Ting of Intel replied and said:

“Intel is working on implementation of UEFI 2.5 HTTP boot support.”

Samer El-Haj-Mahmoud of HP also replied, and said:

“Both HTTP Boot and Redfish are very new standards. HTTP Boot got standardized as part of UEFI 2.5 in March. Redfish is still not even 1.0 (last published spec is 0.96.0a, with a target 1.0 spec sometime this month according to DMTF). It is expected that implementation will take some time to catch up to the spec. At the same time, PXE and IPMI have been there for quite some time, are implemented across the board on servers (and many clients), and are already in wide use. I do not expect them to go away anytime soon. But the goal is to switch over to HTTP and Redfish/REST over time, especially as they enable new use cases and capabilities that were not possible (or easy to do) before. The first step though is to get the specs implemented. As Ting explained, Intel is working on UEFI 2.5 HTTP Boot implementation (that I expect will show up in EDK2. I see the header files submitted already). DMTF is also working on a Redfish mockup/simulator that can be used to exercise clients. HP ProLiant Gen9 servers already support proprietary flavors of both HTTP Boot (or “Boot from URL”) and Redfish (or the “HP RESTful API”). I do not know of any other servers that implement such technologies at this time.”

So, it sounds like HP is the only vendor that supports UEFI HTTP Boot at the moment, and Intel is working on an implementation. If Intel’s implementation is part of TianoCore, other vendors may use it.

I’m looking forward to a TianoCore implementation, as well as DMTF’s Redfish simulator.

Thanks to Ye Ting and Samer El-Haj-Mahmoud for the answers!

CHIPSEC v1.2.0 Released

The Intel CHIPSEC team just posted the latest version of CHIPSEC, 1.2.0. Release notes excerpt below, see the full text on the github site, with known issues:

New/updates modules:
* Merged common.secureboot.keys module into common.secureboot.variables module
* Updated tools.secureboot.te module to be able to test PE/TE issue on Linux or UEFI shell
* Updated tools.smm.smm_ptr module

Updates:
* Added the *controls* abstraction. Modules are encouraged to use “get_control“ and “set_control“ when interacting with platform registers. This permits greater flexibility in case the register that controls a given feature or configuration changes between platform generations. The controls are defined in the platform XML file. At this time, only a small number of controls are defined. We plan to move existing modules over to this new mechanism.
* Added XML Schema for the XML configuration files
* Support for reading, writing, and listing UEFI variables from the UEFI Shell environment has been added.
* Added support for decompression while SPI flash parsing via “decode“ or “uefi decode“ commands in Linux
* Added basic ACPI table parsing to HAL (RSDP, RSDT/XSDT, APIC, DMAR)
* Added UEFI tables searching and parsing to HAL (EFI system table, runtime services table, boot services table, DXE services table, EFI configuration table)
* Added DIMM Serial Presence Detect (SPD) ROM dumping and parsing to HAL
* Added “uefi s3bootscript“ command parsing the S3 boot script to chipsec_util.py
* Added virtual-to-physical address translation function to Linux/EFI/Windows helpers
* Added support of server platforms (Haswell server and Ivy Town) to chipset.py

More Information:

https://github.com/chipsec/chipsec

VMWare partners with Intel Security for cloud IPS service

A few days ago, VMWare announced a solution with Intel/McAfee for additional security. McAfee Network Security Platform (NSP) service will be providing Intrusion Prevension Services (IPS) for their data center. McAfee was acquired by Intel Security. It wasn’t clear from the press release how virtual firmware is impacted with this new security service.

“This collaboration between VMware and Intel Security delivers clear value for our mutual customers, enabling them to have consistently high levels of threat protection for traffic both inside the data center and at the data center perimeter. The tight integration between VMware NSX and Intel Security’s McAfee NSP means security controls follow application workloads, allowing customers to dynamically scale security services,” said Tom Corn, Senior Vice President, Security Products, VMware.

“With the Intel Security and VMware integration, McAfee NSP provides integration within VMware NSX to allow customers to apply advanced security capabilities for the protection of east-west traffic in the data center, which makes up the majority of traffic in these environments.  The McAfee NSP takes advantage of the VMware NSX platform’s distributed micro-segmentation enforcement and simplified automated provisioning, creating a zero-trust environment to automatically help protect organizations’ assets against advanced threats,” said Raja Patel, General Manager for the Network Security Business Unit, Intel Security.

More Information:

http://www.vmware.com/company/news/releases/vmw-newsfeed/Intel-Security-and-VMware-Announce-Intgrated-Solution-For-Automating-And-Accelerating-Advanced-Security-Services-Deployment/2892242-manual

VZ recent blog posts

Vincent Zimmer of Intel has been busy blogging the last few days… 🙂

His personal blog has a few topics related to UEFI. He talks about evolving EFI-based procotols, using hardware interrupts in the polled driver model-based UEFI OS, and MdePkg library design, and Intel TXT along with Secure Boot and Measured Boot, and member of a recently former Intel employee, George Cox, who recently passed on.

At work, Vincent wrote a blog for the Intel Firmware blog. In this blog post, he covers some background on the “Beyond BIOS” white paper series that they’ve been doing for a decade.

(These are both blogs I follow, and I’ll list on the blogroll once I figure out how to use WordPress to expose the blogroll.)

There are MANY links in these two blog posts, a few of them are new. Worth reading, if you care about UEFI on Intel.

More Information:

http://vzimmer.blogspot.com/2015/06/guids-revisions-interrupts.html
http://vzimmer.blogspot.com
http://firmware.intel.com/blog/beyond-bios
http://firmware.intel.com/blog

Spring Plugfest presentations uploaded

The PDFs of the presentations from last months’ UEFI Forum plugfest have been uploaded to uefi.org.

http://www.uefi.org/learning_center/presentationsandvideos
(scroll about half-way through the page, after the Youtube videos…)

* System Prep Applications – Powerful New Feature in UEFI 2.5 – Kevin Davis (Insyde Software)
* Filling UEFI/FW Gaps in the Cloud – Mallik Bulusu (Microsoft) and Vincent Zimmer (Intel)
* PreBoot Provisioning Solutions with UEFI – Zachary Bobroff (AMI)
* An Overview of ACPICA Userspace Tools – David Box (Intel)
* UEFI Firmware – Securing SMM – Dick Wilkins (Phoenix Technologies)
* Overview of Windows 10 Requirements for TPM, HVCI and SecureBoot – Gabe Stocco, Scott Anderson and Suhas Manangi (Microsoft)
* Porting a PCI Driver to ARM AArch64 Platforms – Olivier Martin (ARM)
* Firmware in the Data Center: Goodbye PXE and IPMI. Welcome HTTP Boot and Redfish! – Samer El-Haj-Mahmoud (Hewlett Packard)
* A Common Platforms Tree – Leif Lindholm (Linaro)

This’ll be a very short blog, as I’m busy reading 9 new PDFs… 🙂 I’ll do blogs on some these specific presentations in the coming days.

 

 

Apple UEFI bootkit

There’s stories in multiple news sites today about a UEFI firmware bug in Apple systems, by security researcher Pedro Vilaça (@osxreverser), that is somewhat similar to Thunderstrike.

According to Dennis Fisher’s story at Threatpost, “The vulnerability can be exploited remotely, Vilaca said.” Threatpost also states: “He added that he believes Apple may know about this vulnerability already, as it doesn’t seem to be present on machines sold after about the middle of 2014.

If you have Apple — or perhaps other UEFI-based — hardware, you should follow this story!

More information:

Firmware Bug in OSX Could Allow Installation of Low-Level Rootkits


http://www.pcworld.com/article/2929172/apple-vulnerability-could-allow-firmware-modifications-researcher-says.html
http://www.securityweek.com/efi-zero-day-exposes-macs-rootkit-attacks-researcher

coreboot and Chrome OS upstreaming

I mainly work with UEFI technology, and don’t know much about coreboot, nor Chrome OS. I’m new to these tech, and learning them… 🙂

For a while, I thought coreboot was pretty inactive, but I now realize much of the coreboot activity has been taking place in Chrome OS. It appears that some of this work is now being upstreamed to the main coreboot.

From the coreboot blog:

“In the last months there was lots of activity in the coreboot repository due to upstreaming the work that was done in Chrome OS’ branch. We’re happy to announce that both code bases are again relatively close to each other. In the last 7 months, about 1500 commits that landed in coreboot originated in Chrome OS’ repository (of about 2600 total). Those came from 20 domains, which represent pretty much every part of the coreboot community: well known private and commercial coreboot contributors, but also BIOS and silicon developers as well as device manufacturers. Significant contributions that went into the tree recently were written with active support by Broadcom, Imagination Technologies, Intel, Marvell, Nvidia, Qualcomm, and RockChip.”

“In the future, Chrome OS will move over to a new branch point from upstream, and work on strategies to avoid diverging for two long years again. Instead, we’re looking for ways to keep the trees closer while also avoiding flooding the coreboot.org developer base with hundreds of patches. More on that as it is implemented.”

Some features that’ve been recently added include:
* new MIPS support
* improved ARM support, for SoCs by Broadcom, Marvell, Qualcomm, and RockChip
* an improved, safer method to declare the memory map on devices
* effort to get Chrome OS’ verified boot support
* update the flash image format to allow for safer incremental updates

This looks like great news for coreboot! I’ll have more blog entries about coreboot and Chrome OS in the near future.

More Information:

Report on Chrome OS upstreaming


http://coreboot.org/
http://www.chromium.org/chromium-os/2014-firmware-summit
https://www.chromium.org/chromium-os/chromiumos-design-docs/verified-boot

Upcoming features in UEFI Python port

Today, on the EDK2-devel mailing list, Daryl McDaniel of Intel gave us a hint about upcoming changes in the UEFI port of CPython 2.7x. I am looking forward to UEFI  ctypes, as well as threading!

More Information, quoting Daryl’s posting:

Later this year I will be committing a port of the ctypes module for EDK II Python.  The built-in edk2 module will also be extended to provide a pointer to the SystemTable which can then be used with the ctypes module to access any of the Boot or Runtime Services as well as loading protocols and accessing their member functions and data. I hope to follow that with some pure Python code that allows direct access to UEFI functionality without the user having to know how to use ctypes.  This is not on the official plan but is just something I would like to do so I can’t give a definite schedule for it. Things that are queued up (in no particular order) are:
    *  command-line switch to force stderr to stdout, similar to 2>&1 redirection.
    *  ctypes for IA32 and X64
    *  threading
    *  4Suite-XML
    * cDeepCopy
    *  zope interface
    *  UEFI wrappers for ctypes

VZ on network usage of UEFI 2.5

Vincent Zimmer of Intel recently gave a presentation on use of UEFI 2.5 and Cloud-related issues. The talk was given at the Open Compute Project, and recently reprised at the Spring UEFI Forum event. The focus is UEFI-centric use of network booting, and firmware updates. This is a useful presentation to help understand one way UEFI uses it’s network stack.

More information:

http://firmware.intel.com/blog/uefi-and-cloud

Spring UEFI Forum agenda announced

The UEFI Forum Spring event is happening in Tacoma.WA.US this coming week. They just announced the presentations for the event:

* Zachary Bobroff, AMI – PreBoot Provisioning solution with UEFI
* Kevin Davis, Insyde – System Prep Applications, A Powerful New Feature in UEFI 2.5
* Olivier Martin, ARM – Porting a PCI driver to ARM AArch64 platforms
* Lief Lindholm, ARM – Demonstrating a common EDK2 pltforms & drivers tree
* Dick Wilkins, Phoenix – UEFI FIrmware – Securing SMM
* Gabe Stocco and Scott Anderson, Microsoft – Windows Requirements for TPM, HVCI and Secure Boot
* Jeremiah Cox
* Vincent Zimmer, Intel – Filling UEFI/FW Gaps in the Cloud
* David Box, Intel – An overview of ACPICA userspace tools
* Samer El-Haj-Mahmoud, HP – Firmware in the Datacenter: Goodbye PXE and IPMI. Welcome Http

Typically, the UEFI Forum makes slides for these presentations available on their web site a few weeks later…

More information:
http://www.uefi.org/node/887

 

Linaro makes LUVos-live available for ARM64

LUVos (Linux UEFI Validation — aka luvOS or LUVos, is a Yocto-based Linux distro that helps diagnose UEFI firmware. LUV-live is a liveimage boot version of LUVos. LUV-live also includes other hardware/firmware tools, such as BITS, FWTS, and CHIPSEC.

Intel-based LUV was initially only targeting Intel platforms. But LUV is an open source project, with a healthy community of contributors.

Recently Linaro has been porting LUV to ARM64. Thanks, Linaro! This is great news for ARM64 Linux enterprise hardware. Once Linaro ports CHIPSEC to ARM, it’ll be a very good day for ARM64 firmware defensive security tools.

It would be nice to consider an ARM32 port, as well as ARM64. All devices need bootkit detection tools, not just enterprise-class systems. 🙂

[Someone please wake up AMD. Right now, AFAICT, their platform now has the worst defensive tools. They need a LUV-live with a CHIPSEC that works on ARM systems.]

https://wiki.linaro.org/LEG/Engineering/luvOS

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

Book Review: Embedded Firmware Solutions

Embedded Firmware Solutions: Development Best Practices for the Internet of Things
APress Media
ISBN 978-4842-0071-1
February 2015
Jiming Sun, Marc Jones, Stefan Reinauer, Vincent Zimmer
http://www.apress.com/9781484200711

[I recently finished reading this book. Sadly, I didn’t know about it until the other day, after my LinuxFestNorthWest talk on firmware security tools, someone from Sage pointed out that I omitted this from my More Information slides.]

If you care about firmware development — or just understanding current firmware architecture — you should have this book. It is the only current book with information about modern firmware in use today. The authors are all experienced and well-known firmware developers, including members of the Coreboot and UEFI teams, and there is also an impressive list of tech reviewers. There are 4 areas that this book focuses on:
* Intel Firmware Support Package (FSP), and it’s use in Coreboot and UEFI.
* UEFI and it’s dev platform.
* Coreboot and Chrome use of it.
* Intel Quark and UEFI firmware.

Intel Press has a handful of other UEFI books, but they are years old, this book is only a few months old, and has fresher details on UEFI. I don’t know of any other book with this kind of information on Coreboot, or on Intel FSP. There are a variety of books on Intel’s Minnowboard and Quark/Galileo IoT hardware: most of those books talk about how to write user-level apps, this is the only book that talks about updating the firmware of Intel IoT devices.

I’m looking forward to a second edition in a year or so, once tech changes enough.