CHIPSEC training at TROOPERS

The Intel CHIPSEC team doesn’t get out much to give training to the public often, so this upcoming 2-day of CHIPSEC training at TROOPERS is nice!

Security below the OS with CHIPSEC framework
Oleksandr Bazhaniuk, Yuriy Bulygin

A variety of attacks targeting platform firmware have been discussed publicly, drawing attention to the pre-boot and firmware components of the platform such as BIOS and SMM, UEFI secure boot and OS loaders. This workshop provides a hands-on opportunity to learn how to use an open source CHIPSEC framework https://github.com/chipsec/chipsec to test systems for vulnerabilities in low-level platform firmware components, problems with firmware security protections as well as develop your own modules in CHIPSEC which test for known issues or implement tools identifying new issues. Agenda:

* Introduction to platform hardware and access with CHIPSEC
* Introduction to platform firmware such as BIOS, UEFI firmware, SMI handlers
* Overview of main components of CHIPSEC framework
* Analyzing main firmware components and configuration
* Assessing systems for vulnerabilities in the BIOS and other firmware
* Developing vulnerability testing modules
* Developing fuzzers for firmware interfaces and other security tools
* BIOS forensics with CHIPSEC

https://www.troopers.de/events/troopers16/567_security_below_the_os_with_chipsec_framework/

William Leara reviews UEFI Tool

William Leara, a firmware engineer at Dell, has a new blog post on Nikolaj Schlej’s UEFI Tool. He shows how to use it, starting with using Intel’s Flash Programing Tool (FPT) to acquire a BIOS image. Lots of screenshots of the various menu UI components of this GUI tool.

“It is extremely useful for interrogating and manipulating the components of a UEFI BIOS image.  Download it and give it a test drive today!”

Full post:
http://www.basicinputoutput.com/2016/02/uefitool.html

efitools now available for ARM

James Bottomley has a few new blog posts, two on efitools availability for ARM, and another on a container model for UEFI.

efitools for arm released

efitools arm 32 bit build fixed

Constructing Architecture Emulation Containers

[…] the problem: how to build and test efitools for arm and aarch64 while not possessing any physical hardware.  The solution is to build an architecture emulation container using qemu and mount namespaces such that when its entered you find yourself in your home directory but with the rest of Linux running natively (well emulated natively via qemu) as a new architecture.  […] However, there’s a problem here: the installed binary emulator usually runs as /usr/bin/qemu-${arch}, so if you’re running a full operating system container, you can’t install any package that would overwrite that.  Unfortunately for me, the openSUSE Build Service package osc requires qemu-linux-user and would cause the overwrite of the emulator and the failure of the container.  The solution to this was to bind mount the required emulator into the / directory, where it wouldn’t be overwritten and to adjust the binfmt_misc paths accordingly. […]

Constructing Architecture Emulation Containers

build-container

FPMurphy on TPM access via UEFI

Finnbarr P. Murphy does not blog often, but each post is usually very well written, and often focused on using some UEFI Shell commands to do some specific task. In the current post, the topic is accessing TPM’s features from the UEFI Shell, and it is called “part 1”, with more to come!

“Why an I writing this series of posts? Because there are few published examples of working UEFI code that interacts with a TPM. Such example code is useful to security researchers and computer forensics practitioners.”

http://blog.fpmurphy.com/2016/02/accessing-tpm-functionality-from-uefi-shell-part-1.html

FreeBSD 10.3.beta2’s UEFI changes

Excerpting Phoronix:

Over the past week were some fixes/improvements around FreeBSD’s UEFI support, “The UEFI ZFS loader has been updated to support the latest ZFS Boot Environment (BE) loader menu features” and “The UEFI boot loader received several improvements: /boot/config and /boot.config files now are adhered to, multi device boot support works and command line argument parsing has been added.”

http://www.phoronix.com/scan.php?page=news_item&px=FreeBSD-10.3-Beta-2
https://lists.freebsd.org/pipermail/freebsd-stable/2016-February/084145.html
https://www.freebsd.org/relnotes/10-STABLE/relnotes/article.html

new EFI-headers project

teodori-serge has created a new Github project called “EFI-headers” (for C language), with a comment of “EFI headers” (that was the entire comment, no excerpting). It appears to be a new implementation of headers to define UEFI’s interface, not tied to Tianocore’s EDKII or GNU-EFI’s headers. These might become useful if you have to build EFI code outside of EDK2 or GNU-EFI. Maybe one day we’ll figure out what plans teodori-serge has for these…

https://github.com/teodori-serge/efi-headers

Tony Mangefeste, new Tianocore community manager

Tony Mangefeste of Intel is the new “Community Technology Lead, Tianocore Community Manager”. Yesterday he posted a message to the edk2-devel mailing list with an introduction. Two excerpts:

“I’m your new Tianocore community manager. As best as I can tell, no one has had this role, and I’m the first. And I’m thrilled to have the opportunity to help Tianocore evolve into an awesome-er OSS program.”

“What’s going to change with Tianocore? I hope much positive change will come. More details will follow in the coming weeks. As many of you know, several of our members (led by Erik, Jordan) have been leading the efforts to move to GitHub.  That’s just the tip of the iceberg of improvements that are coming.  If there are barriers to contribution levels, I want to help knock those down.  If we can’t knock them down, I want to navigate around them.”

Full post:
http://article.gmane.org/gmane.comp.bios.edk2.devel/7458

He has just created new Tianocore feeds on Twitter and Google+:
https://twitter.com/tianocore/
https://plus.google.com/communities/104320775708339899382

I noticed a non-ISO-licensed tree in the new Github tree, which may be helpful for Linux, a home non-BSD FOSS code. I hope Tianocore appropriately encourages and maintains this in conjunction with the BSD tree. I hope that in addition to Twitter and Google+ posts, the community manager helps with communinty-led questions about Tianocore, like the FW_OS_Forum. So far this list does not appear to useful for community. It’d be great to see UEFI Forum and it’s members generate a GSoC for Tianocore, most than just maintaining a wishlist of projects on their wiki. I’d like to see more work with UEFI team with coreboot and U-Boot projects using EFI as a payload. I really wish UEFI forum was a bit more open in their events. Right now events are only for members, and the only public events are ‘developer roadshow’-style groomed subset talks. Anyway, enough of me wondering about how Tianocore could do community better. If you have some ideas, contact Tony.

PLUG: UEFI Tuesday

If you are in the Philadelphia area, the Philly LUG has a talk on UEFI by Rich Mingin:

This month, PLUG North will feature a talk on UEFI by Rich Mingin. UEFI is a firmware interface that is displacing the traditional BIOS firmware on PCs. Find out more about how it interacts with Linux and other FOSS operating systems in this presentation.

http://lists.netisland.net/archives/plug/plug-2016-02/msg00019.html

http://www.phillylinux.org/meetings.html

UEFI VirtualBox tutorial

There’s another new Github project related to UEFI, this one is a turorial using UEFI undre VirtualBox. Most use of virtualized UEFI occurs under QEMU, but VirtualBox also supports UEFI’s OVMF (Open Virtual Machine Firmware) format, so it is nice to see more documentation on using UEFI with VirtualBox, not only QEMU.

Tutorial on making UEFI with CMake and VirtualBox

UEFI Bare Bone Exercise

by Emanuele Ruffaldi using CMake,mxe and VirtualBox/Qemu

Related instructiosn from OSDEV: http://wiki.osdev.org/UEFI_Bare_Bones Other related project (Make+QEmu): – https://github.com/tqh/efi-examplehttp://www.rodsbooks.com/efi-programming/hello.html

Requirements:
 *  GCC Cross Compiler x86_64-w64-mingw32. MXE is fine
 * MTools
 * GNU-efi

[…]

 

https://github.com/eruffaldi/uefiboot

Protecting Linux from systemd’s EFI attack

Peter Jones of Red Hat has submitted a patch to the Linux-EFI mailing list, which helps with the recent systemd attack against Linux’s EFI. Patchset email excerpted below:

Preventing “rm -rf /sys/firmware/efi/efivars/” from damage

Here’s a patchset to make all the variables in efivarfs that aren’t well known to be reasonably safe to delete be immutable by default. This should alleviate the danger of somebody accidentally using “rm” to remove some proprietary file that turns out to be important to the platform, which for some reason it also can’t regenerate during POST. In all cases this is just preventing the user from accidentally triggering a major security problem with their underlying firmware, but stopping accidents isn’t a bad thing.  These firmwares still need CVEs and updates to fix them.  Maybe using ESRT and fwupd 🙂

For more information, see the linux-efi mailing list archives.

Systemd, UEFI, and efivarfs bricking concerns

 

Dell info on Linux firmware updates

Regarding the new firmware update service available for Linux OEMs:

https://firmwaresecurity.com/tag/fwupd/

There is a new article from Dell on this topic:

(Published on behalf of Mario Limonciello, OS Architect of Dell Client Solutions Group’s Linux Engineering team.)

I’m happy to announce that starting with the Dell Edge Gateway 5000 we will be introducing support to natively flash UEFI firmware under Linux.  To achieve this we’re supporting the standards based UEFI capsule functionality from UEFI version 2.5.  Furthermore, the entire tool chain used to do this is open source. Red Hat has developed the tools that enable this functionality: fwupd, fwupdate, & ESRT support in the Linux kernel.  For the past year we have been working closely with Red Hat, Intel, & Canonical to jointly fix hundreds of issues related to the architecture, tools, process, and metadata on real hardware.  Dell will be publishing BIOS updates to the Red Hat created Linux Vendor Firmware Service (LVFS).  Red Hat provides LVFS as a central OS agnostic repository for OEMs to distribute firmware to all Linux customers. […]

http://en.community.dell.com/techcenter/b/techcenter/archive/2016/02/02/dell-firmware-updating-under-linux

Dell — along with Red Hat, apparently — are setting a great example, I hope other OEMs do as well with Linux. 🙂 It makes me think Dell is working to deal with this recent comment of William (of Dell):

BITS 2073 released

Burt Triplett has announced the release of BITS (BIOS Implementation Test Suite) version 2073:

– efi: Support EFI_IP4_CONFIG2_PROTOCOL and associated data structures

– _socket: Use EFI_IP4_CONFIG2_PROTOCOL if available, falling back to EFI_IP4_CONFIG_PROTOCOL

 BIOSes based on current versions of EDK2, including current OVMF, only support EFI_IP4_CONFIG2_PROTOCOL, and drop support for EFI_IP4_CONFIG_PROTOCOL.  Support configuring IPv4 via the newer protocol, falling back to the older protocol for compatibility with existing BIOSes.

  In either case, reuse the existing IPv4 configuration if present, and only kick off DHCP if not already configured.  This also allows systems that require manual IPv4 configuration to perform such configuration (via the EFI shell, the BITS Python interpreter, or any other means) and subsequently use that configuration with BITS.

More info:
http://biosbits.org/downloads/bits-2073.zip
https://github.com/biosbits/bits/ (tag bits-2073)
https://lists.01.org/pipermail/bits/2016-January/000001.html

PXE-config: PXE config files for BIOS and UEFI

There’s a new github project for BIOS/UEFI-centric PXE use, called PXE-config:

PXE config files for Legacy BIOS and UEFI netboot installs; also contains kickstart files for automated CentOS, Fedora, etc. installs. This repo contains various config files including PXE boot menu config files & kickstart files for unattended installs over PXE boot. It does not contain /etc/dnsmasq.conf, however, which contains PXE server settings for dhcp, tftp boot, and detecting client architectures (Legacy BIOS vs UEFI). dnsmasq.conf can be found in my jun-dotfiles repo on github.

https://github.com/gojun077/pxe-config

Systemd, UEFI, and efivarfs bricking concerns

https://github.com/systemd/systemd/issues/2402

UEFI 2.6 spec changes

Here’s a bit more information about UEFI 2.6, from the changelog in the spec. There are 25 2.5 errata changes, and 39 new 2.6 features, ranging from October 2015 to January 2016.

UEFI 2.5 errata:
1209 UEFI networking API chapter 2.6 requirements errors
1363 Short form URI device path
1365 7.4 Virtual Memory Services lists Section 2.3.2 through Section 2.3.4. incorrectly
1381 Remove informative content in 12.6.1
1388 Missed memory type
1398 Errata update to the runtime GetVariable operation documentation
1399 Clarification for EFI_BROWSER_ACTION_REQUEST_RECONNECT
1405 Errata in table 271 in Appendix O
1407 Networking errata – EFI_HTTP_STATUS typos
1410 Clarifications in appendix O
1417 Add HttpMethodMax to EFI_HTTP_METHOD enum
1418 Inconsistent issues in DNS
1419 Supplicant protocol using same GUID as TLS protocol
1420 GetNextHighMonotonicCount clarification
1421 Misc HTTP API typos
1424 Incorrect link in Section 22.1 FMP GetImageInfo()
1426 UEFI 2.5 typo
1441 UEFI2.5 errata – UNDI Protocol Clarification
1451 Memory Map Consistency
1468 Errata on UEFI Supplicant protocol
1469 UNDI Errata – add more statistics
1472 ATA Pass Thru Errata
1476 Update to Indicate that CloseEvent Unregisters Corresponding Protocol Notification Registrations
1477 Allow CloseEvent to be called within the Notification Function
1481 new network config2 protocol data structure has a magic number

UEFI 2.6 new features:
1357 ARM CPER extensions
1402 Add EFI_BROWSER_ACTION_SUBMITTED
1471 SD/eMMC PassThru Protocol update (follow up to mantis 1376)
1376 SD/eMMC PassThru Protocol
1408 EFI HII Font EX protocol and EFI HII Font Glyph Generator protocols
1414 Generalisation of communication method in Appendix O
1467 New API – EFI_WIRELESS_MAC_CONNECTION_II_PROTOCOL
1480 Refine Progress description in EFI_KEYWORD_HANDLER_PROTOCOL
1452 Minor edits to 0001409
1409 EFI HII ImageEX protocol and EFI HII Image Decoder protocols
1466 UEFI Ram disk protocol
1383 Adding an EraseBlocks() function to a new protocol
1479 UEFI Properties Table Clarification
1491 supplicant errata
1492 wireless mac connection protocol II errata
1493 Updates to the SD_MMC_PASS_THRU interface
1494 Errata against UEFI 2.5 Properties Table
1496 Bad table reference in 13.2 EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL.Configuration()
1501 Define the usage of the “Address Space Granularity” field is defined in the PCI Root IO
1502 PCI IO Define how to use the Address Translation Offset for systems that are not mapped 1:1
1507 Insufficient qualification of page attributes for AArch64
1508 Lack of flexibility and realism in exception level choice when calling runtime services
1509 EFI_PLATFORM_TO_DRIVER_CONFIGURATION_PROTOCOL Response to unsupported ParameterTypeGuid
1516 Editorial comments against 2.6 Draft
1518 Comments against 2.6 Draft
1519 Version for the next UEFI spec is…
1521 comment against UEFI.next draft – M1479
1522 AArch64 bindings Alignment bit errata
1523 Comments against 2.6 Draft
1533 Bugs in the HTTP usage example
1534 Editorial comments against 2.6 Final Draft
1536 UEFI 2.6 Errata : IMAGE EX Protocol and EFI HII Image Decoder protocol Errata
1538 UEFI TLS errata
1539 New EFI_HTTP_ERROR Status Code
1542 UEFI 2.6 supplicant errata
1543 ip4/6 config policy errata/2.6 update
1544 DNS lookup API spelling
1547 Clarify requirements for setting the PK variable.
1548 Clarify boot procedure when file name is absent

The numbers mentioned are the Mantis issue tracking number that UEFI Forum uses to track changes in the spec. This mantis database is only available to UEFI Forum members, nonmmembers can ignore these, sometimes you can search for older references to mantis numbers for older UEFI spec features.

ACPI 6.1 released

ACPI v6.1 spec has been released, apparently. I have yet to read it, so not sure what has changed yet.

http://uefi.org/acpi

The UEFI Forum has already started doing EDK-II trunk checkins for 6.1 support for UEFI.

[edk2] [patch] MdePkg: Add ACPI6.1 definition.
Add ACPI 6.1 definitions from the ACPI
Specification Revision 6.1 January, 2016.

MdePkg/Include/IndustryStandard/Acpi61.h | 2375 ++++++++++++++++++++++++++++++
1 file changed, 2375 insertions(+)
create mode 100644 MdePkg/Include/IndustryStandard/Acpi61.h

diff –git a/MdePkg/Include/IndustryStandard/Acpi61.h b/MdePkg/Include/IndustryStandard/Acpi61.h
new file mode 100644

More info:

https://lists.01.org/mailman/listinfo/edk2-devel
.