Giri Mudusuru and Vincent Zimmer of Intel gave a presentation with an overview of Intel FSP 2.0:
A Tour Beyond BIOS Implementing Profiling in EDK II
Jiewen Yao, Vincent Zimmer, Star Zeng, Fan Jeff
The Unified Extensible Firmware Interface (UEFI) and Platform Initialization (PI) specification defines rich execution environments such as Security (SEC), Pre-EFI Initialization (PEI), Driver Execution Environment (DXE), System Management Mode (SMM) and UEFI Runtime (RT) for firmware drivers. There are more and more features added into a firmware. At same time, the firmware still has a resource constrained environment. In addition to functionality, the size, performance, and security are three major concerns of a firmware engineer. This paper introduces several profiling features implemented in EDK II to help the UEFI firmware developer to analyze the size, performance and security of a UEFI firmware implementation.
Getting Started with UEFI HTTP over TLS (HTTPS) Boot on EDK II
HTTP over TLS (HTTPS) boot is a standard implementation for securely booting using the Unified Extensible Firmware Interface (UEFI) over a network device. HTTPS Boot is especially important for clients using potentially insecure networks outside of corporate infrastructure. Security for UEFI HTTPS Boot is provided by the underlying Transport Layer Security (TLS).
This document assumes that the reader is familiar with the EDK II HTTP Boot Getting Started Guide.
Vincent Zimmer of Intel UEFI has posted TWO blog posts, to catch up to.
In the first, he point out some newly-released Intel FSP 2.0 documents:
In the second, he talks about UEFI history, focused on the 2 editions of the Beyond BIOS book (and the recent UEFI reference book in comic book pop culture).
PS: Intel Press, the web pages (including errata) for the Beyond BIOS 2nd Edition and UEFI Shell books are broken. It sucks to have an $80 book with a broken web site. Nothing personal, it seems most tech book publishers are terrible at persistant web sites and ‘cool URIs’. 😦
Vincent has a new blog post on Intel FSP (Firmware Support Package), discussing the phases of firmware init, and how FSP works with both coreboot and UEFI.
First, Vincent replied to my last FSP post with an URL to another FSP-related spec, the Boot Setting File (BSF) spec, see the comments here:
Second, Vincent has two posts of his own on FSP, I may’ve blogged about one, but I believe the other one is new, there’s a lot of new FSP links to start learning…:
Vincent Zimmer of Intel has a new blog post, on UEFI’s EDK-II and Intel FSP (Firmware Support Package), and how the FSP works with the EDK-II. Good background, with lots of links.
For more information on UEFI and FSP, also read the APress book, which Vincent is one of the authors:
Vincent Zimmer of Intel (and UEFI Forum) has a blog post about the recent Open Compute Project Summit, discussing UEFI and firmware updates, especially network-based updates, and the issues involved. There’s a presentation (with slides and video) from the OCP Summit to watch, blog has multiple pointers.
The Intel Firmware blog has a new post from last week, talking about how UEFI’s memory structures evolve from init onward:
A question that is often asked is “how does the UEFI memory map evolve, from UEFI PI PEI to DXE to the data structures exposed to the operating system via the GetMemoryMap() boot service?” […]
Vincent Zimmer of Intel has a new blog post, explaining how UEFI’s HII user interface stuff works:
[…] The The x-UEFI configuration language is now a reality. The latest keywords can now be found at http://uefi.org/confignamespace. This list should grow over time as more configuration data emerges based upon new platform technologies, features in the UEFI and other industry standards, etc. This type of facility helps provide infrastructure to provide visibility into ‘Is Features XYZ enabled.” A common instance of this is virtualization technology, hyper threading, and other art managed by the platform. Going forward, I can imagine OS viewer utilities, maybe /dev/hii in Linux and an associated Microsoft Windows interface, to exposing this information. The EDKII community on tianocore.org ought to investigate some simple shell applications to export the information, too. […]
Full blog post:
The config namespace already has dozens of variables:
I am looking forward to someone writing a security test tool that works with this database. 🙂
The January 2016 Seattle Hardware Startups event will be firmware focused, hosted by our local group, the Pacific NorthWest FirmWare Hackers (PNWFWH), topics will be on U-Boot and UEFI, Meetup announcement below. If you are in the Seattle area later this month, drop by!
What: Seattle Hardware Startup: Kirkland Edition
When: Thursday, January 28, 2016, 6:00 PM to 8:00 PM
Where: Nytec Innovation Center, 416 6th Street South, Kirkland, WA
This month we are welcoming Pacific NorthWest FirmWare Hackers. PNWFHW meets randomly at various places, speaking on development and security topics of modern system firmware (UEFI, U-Boot, core boot, etc.). I am pleased to have them lead an event for us.
1. The first speaker is Emergency Mexican (his DEF CON goon nym). He works at a local hardware startup working on ARM32 systems. He’ll be speaking on using building custom payloads with the U-Boot boot loader.
2. The second speaker is Vincent Zimmer, a senior principal engineer at Intel, working on UEFI. Vincent chairs the UEFI Forum network and security subteams. Vincent will talk about the latest updates in the UEFI specifications for security and networking. He’ll also discuss open source community updates.
Please RSVP early so we call the pizza man and make proper arrangements.
PS: Did you know that January 15th is Hardware Freedom Day?
Earlier I was starting to create a list of Twitter feeds of firmware-related security researchers, since many use Twitter exclusively these days. But I have been hesitant to continue this, in case I don’t know about some researchers and not list them, etc. I’d rather let others manage the list, and luckily Jacob Torrey created a Twitter ‘firmware-security’ list so you can join yourself and I don’t have to create/maintain a list!
In addition to Twitter, there still are a few people who use blogs. Vincent Zimmer has been blogging on firmware for a long time, and he’s got the definitive post on firmware blogs:
I don’t know anything about Usenet, IRC/XMPP/IM, Reddit, Facebook, LinkedIn, Google+, or other social network communities which cover firmware security issues. If you know of one, please leave a comment on this blog (see left), or email me (see upper right).
For a future blog post, I’ll create a list of firmware-related mailing lists.
The Open Compute Project’s Hardware group is starting a new Firmware focus group, focusing on UEFI Forum and DMTF technologies. The group is led by Mallik Bulusu of Microsoft and Vincent Zimmer of Intel.
“During our last meeting, we had a very good discussion about standardizing UEFI interfaces and what make sense and does not make sense. There is also a need to standardize and streamline FW updates, define bare metal provisioning scenarios and interfaces, extend security framework to include auditing and monitoring, UEFI configuration management, etc. Also, our alliance groups (UEFI, DMTF) are working on similar or closely related technologies. We want to make sure we work closely with them to make sure we are aligned. Towards that end, Mallik Bulusu and Vincent Zimmer are willing to bootstrap this effort and lead a subgroup that is focused on this. Anyone interested in this topic and willing to contribute please send an email to Mallik and Vincent expressing your interest. The goal here is to a) come up with a specification that capture OCP member specification and b) working with our members and alliance partners to get buy-in and implementations for those specs. We will discuss this further in our upcoming monthly meeting.”
For more information, see the posting on the OCP Hardware Management list, and their next upcoming monthly meeting.
Earlier today, Matthew Garret posted a problem on Twitter about Intel Linux and Intel TXT mode:
Later that day, Vincent Zimmer of Intel is apparently helping to get that Intel project working with UEFI:
A few weeks ago, a similar thing happened with Intel SGX. Intel is lucky to have Vincent Zimmer, who is very engaged with Linux security/development community, in helping to fix Intel projects to properly support UEFI. Many large companies do not have this kind of public individual involvement.
Vincent Zimmer of Intel wrote a blog on recent Intel UEFI activities relating to open source. He talks about a few things, including “SMI Transfer Monitor (STM)”, recently announced at Intel Developer Forum. I briefly posted on STM, but barely mentioned any details, better points to information are in Vincent’s current post. I hope to see vendors using this powerful technology in the future.
The other day I learned about Intel KGT:
Then I noticed Matthew Garrett’s twitter feed, saying that it didn’ t work with UEFI… But today I note that Vincent Zimmer of Intel has a new Twitter post, saying that Intel is working on porting KGT to work with UEFI:
Looking forward to UEFI-enabled iKGT!
The Embedded Linux Conference Europe (ELCE) is happening in October. There’s a set of UEFI talks happening at the event:
UEFI Forum Update and Open Source Community Benefits, Mark Doran
Learn about the recent UEFI Forum activities and the continued adoption of UEFI technology. To ensure greater transparency and participation from the open source community, the Forum has decided to allow for public review of all specification drafts. Find out more about this new offering and other benefits to being involved in firmware standards development by attending this session.
What Linux Developers Need to Know About Recent UEFI Spec Advances, Jeff Bobzin
Users of modern client and server systems are demanding strong security and enhanced reliability. Many large distros have asked for automated installation of a local secure boot profile. The UEFI Forum has responded with the new Audit Mode specified in the UEFI specification, v2.5, offering new capabilities, enhanced system integrity, OS recovery and firmware update processes. Attend this session to find out more about the current plans and testing schedules of the new sample code and features.
LUV Shack: An automated Linux kernel and UEFI firmware testing infrastructure, Matt Fleming
The Linux UEFI Validation (LUV) Project was created out of necessity. Prior to it, there was no way to validate the interaction of the Linux kernel and UEFI firmware at all stages of the boot process and all levels of the software stack. At Intel, the LUV project is used to check for regressions and bugs in both eh Linux kernel and EDK2-based firmware. They affectionately refer to this testing farm as the LUV shack. This talk will cover the LUV shack architecture and validation processes.
The Move from iPXE to Boot from HTTP, Dong Wei
iPXE relies on Legacy BIOS which is currently is deployed by most of the world’s ISPs. As a result, the majority of x86 servers are unable to update and move to a more secure firmware platform using UEFI. Fortunately, there is a solution. Replacing iPXE with the new BOOT from HTTP mechanism will help us get there. Attend this session to learn more.
UEFI Development in an Open Source Ecosystem, Michael Krau, Vincent Zimmer
Open source development around UEFI technology continues to progress with improved community hosting, communications and source control methodologies. These community efforts create valuable opportunities to integrate firmware functions into distros. Most prevalent UEFI tools available today center on chain of trust security via Secure Boot and Intel® Platform Trust Technology (PTT) tools. This session will address the status of these and other tools. Attendees will have the opportunity to share feedback as well as recommendations for future open UEFI development resources and processes.
UEFI aside, there’s many other presentations that look interesting, for example:
Isn’t it Ironic? The Bare Metal Cloud – Devananda van der Veen, HP
Developing Electronics Using OSS Tools – Attila Kinali
How to Boot Linux in One Second – Jan Altenberg, linutronix GmbH
Reprogrammable Hardware Support for Linux – Alan Tull, Altera
Measuring and Reducing Crosstalk Between Virtual Machines – Alexander Komarov, Intel
Introducing the Industrial IO Subsystem: The Home of Sensor Drivers – Daniel Baluta, Intel
Order at Last: The New U-Boot Driver Model Architecture – Simon Glass, Google
Suspend/Resume at the Speed of Light – Len Brown, Intel
The Shiny New l2C Slave Framework – Wolfram Sang
Using seccomp to Limit the Kernel Attack Surface – Michael Kerrisk
Tracing Virtual Machines From the Host with trace-cmd virt-server – Steven Rostedt, Red Hat
Are today’s FOSS Security Practices Robust Enough in the Cloud Era – Lars Kurth, Citrix
Security within Iotivity – Sachin Agrawal, Intel
Creating Open Hardware Tools – David Anders, Intel
The Devil Wears RPM: Continuous Security Integration – Ikey Doherty, Intel
Building the J-Core CPU as Open Hardware: Disruptive Open Source Principles Applied to Hardware and Software – Jeff Dionne, Smart Energy Instruments
How Do Debuggers (Really) Work – Pawel Moll, ARM
Make your Own USB device and Driver with Ease! – Krzysztof Opasiak, Samsung
Debugging the Linux Kernel with GDB – Peter Griffin, Linaro
Usenix WOOT 2015 is happening in Washington D.C. later this month. It has a very interesting UEFI security talk:
Symbolic execution for BIOS security
Oleksandr Bazhaniuk, John Loucaides, Lee Rosenbaum, Mark R. Tuttle, Vincent Zimmer, Intel Corporation
May 25, 2015
We are building a tool that uses symbolic execution to search for BIOS security vulnerabilities including dangerous memory references (call outs) by SMM interrupt handlers in UEFI-compliant implementations of BIOS. Our tool currently applies only to interrupt handlers for SMM variables. Given a snapshot of SMRAM, the base address of SMRAM, and the address of the variable interrupt handler in SMRAM, the tool uses S2E to run the KLEE symbolic execution engine to search for concrete examples of a call to the interrupt handler that causes the handler to read memory outside of SMRAM. This is a work in progress. We discuss our approach, our current status, our plans for the tool, and the obstacles we face.
There might be other interesting talks happening there, but none have BIOS/UEFI/firmware in their title/abstract, so I missed them. 🙂
EBC, The EFI Byte Code, is a UEFI feature that supports Intel (Itanium, x86, and x64) instructions in a single bytecode. The Intel C Compiler can target EBC, and UEFI drivers can use EBC instead of native drivers, to save space (1 binary, instead of 3).
The other week I gave a firmware security tools talk at BlackLodgeResearch.org, and Vincent Zimmer of Intel showed up. I had a slide complaining that EBC is only supported by Intel C Compiler, a commercial-only product, and that the UEFI Forum should fund a ‘summer-of-code’-style effort to get EBC into GCC or LLVM CLang. After the talk, Vincent mentioned that ICC had to do a bit of unexpected work to generate EBC, and would blog about it. Well, he did blog about it, a few days ago, just catching up to it, and describe the problem.
If you know of someone on the LLVM CLang or GCC project, please try to add a request for EBC support.
Not only would it be nice to have LLVM CLang work with EBC to have an alternative to ICC, and for LLBVM’s Klee fuzzer (to fuzz UEFI via OVMF), but ALSO because the Capstone Framework RE tool uses LLVM’s intermediate form and would then get EBC support!!
Today, radare2, another RE tool, already has EBC support.
If technically possible, it might be nice if ARM added AArch32 and AArch64 support, and EBC support in their compiler, so that EBC could actually target all UEFI platforms with a single blob. ARM/Linaro already has something that appears to overlap in some ways:
Also, there’s a C#/IL to EBC translation project on Github. If you get it to work, let me know!
In case you missed Vincent Zimmer of Intel speaking at CanSecWest back in March 2015, it gives a good overview of UEFI security technologies.
“UEFI, Open Platforms and the Defender’s Dillema”
I am reminded of this talk, since we just got Vincent to reprise this talk today at BlackLodgeResearch.org, at the monthly DC206 Meeting, which was also the meeting of the Pacific NorthWest FirmWare Hackers (PNWFWH). Vincent was a guest speaker and spoke on UEFI security for a while, mostly QA w/o slides.
I also gave a talk, on UEFI security tools (CHIPSEC, UEFItool, UEFI Firmware Parser, BIOS Diff, BIOS Extract, LUV-live, FWTS, etc.). I’ll cleanup the slides and post them on this blog shortly. Our scheduled lab was a bit flat, due to 2x the presentations, and a BLR-hosted BBQ, and the interest in listening to the QA with Vincent, and the miserable heat. But some of the attendees had already gotten LUV-live working on their systems, and had learned to dump ROMs, which is the first step.
Vincent also helped me understand the UEFI 2.5 feature list, I’ll be working on more blog posts with spec/source and other info on these ~63 items in some upcoming blog posts.
This blog isn’t attempting to cover ALL firmware news issues. I presume you’re reading about elsewhere, and don’t need this blog to tell you about. Especially stories that make it ‘mainstream’, like the recent Apple EFI vulnerability, or the recent Hacking Team’s use of UEFI in their malware.
In general, I go online and try to see what is new with firmware news only once a day, and miss some days. I don’t use Twitter as much as many, so I’m naturally behind-the-times of fresh news. To track UEFI issues with Twitter, here are a few URLs to start with:
For example the Hacking Team’s use of UEFI. Twitter is a good place for this kind of news:
And a few security researchers are starting to dig deeper with research about the malware, such as: