This is also a useful blog post on the topic of beginning SMM drivers:
http://blog.cr4.sh/2015/07/building-reliable-smm-backdoor-for-uefi.html
as is this:
Tag: UEFI
7-Zip adds UEFI support
Interesting, I just noticed that 7-Zip can read UEFI containers. Excerpt from today’s announcement on BetaNews:
After five years of stop-start development, 7-Zip has just released a new stable version 15.2. It’s been a long wait, but if you’re still using the latest stable build — 9.20 — then there are plenty of reasons to upgrade. There’s support for unpacking many more containers: UEFI BIOS files, WIM files, RAR5 archives, ext2/ ext3/ ext4 images, GPT, VMDK, and single file QCOW2 and VDI images. […]
(I think this support has been in 7-Zip since 2011, but I am just noticing it, and they are announcing it like it is new…)
http://www.7-zip.org/history.txt
http://sourceforge.net/p/sevenzip/discussion/45797/thread/7b27c6ac
http://sourceforge.net/p/sevenzip/discussion/45797/thread/8eb27f98
Determining Windows partition information
Patrik Suzzi has an article on GPT partitions, and how to determine if you have MBR or GPT:
The article is written for Windows users, and has lots of screenshots, looks to be informative!
http://www.multibooters.com/guides/determine-if-hard-drive-is-mbr-or-gpt.html
Using UEFI’s network stack
Tore Anderson has a new blog post on using UEFI with PXE remote boot over IPv6:
https://twitter.com/toreanderson/status/666176213271072768
http://blog.toreanderson.no/2015/11/16/ipv6-network-boot-with-uefi-and-ipxe.html
I’m glad they used PXE, I am not sure UEFI HTTP boot works with IPv6 yet, initial checkin was for IPv4 only. 🙂
CHIPSEC training at TROOPERS!
It appears that two of the Intel CHIPSEC team — Oleksandr Bazhaniuk and Yuriy Bulygin — will be teaching CHIPSEC at TROOPERS next year in Germany!
https://twitter.com/daniel_bilar/status/667386337171935232
https://www.troopers.de/events/troopers16/567_security_below_the_os_with_chipsec_framework/
CHIPSEC aside, there is other hardware security training going on at TROOPERS as well.
https://www.troopers.de/troopers16/trainings/
Slides from The Rootless Monster’s World Tour
The Rootless Monster has been giving a few recent presentations on UEFI security, many new documents to read by this researcher:
https://reverse.put.as/2015/11/06/london-and-asia-efi-monsters-tour/
misc_util: misc utils for UEFI
Daniel Lin created a new UEFI-centric project on Github last week called “misc_util”. Well, named, it contains miscellanous utilities, 3 for now:
* check_override: GUI script to show AptioV override folder and double click to open with Beyond Compare
* showdep: Show UEFI .depex section in human reable form
* pdtpacker: Pack up Intel ISS without MPDT header into a single PDT.binary with MPDT header because of RC will check the header
https://github.com/nitpicker/misc_util
FWTS 15.11.00 released
Alex Hung of Canonlical has announced the release of FWTS (FirmWare Test Suite) version 15.11.00, the November 2015 quarterly release, with multiple changes to the UEFI and ACPI tools.
= Significant Updates =
* Update ACPICA to version 20150930
= New Features =
* Add in the notion of ACPI compliance tests.
* MADT subtables: Local SAPIC structure has 3 reserved bytes, not 1
* ACPI: MADT: update GICC flag checks for ACPI 6.0
* ACPI: MADT: further update to GICC flag checks for 6.0
* acpi: method: skip scope names in method_evaluate_method
* acpi: method: add _GPE test
* acpi: method: add _TSN test
* acpi: method: add _TFP test
* acpi: method: add _EC test
* acpi: method: add _CWS test
* acpi: method: add _BTH test
* auto-packager: mkpackage.sh: add xenial
* acpi: tpm2: add check for zero control area address (LP: #1506442)
* securebootcert: change fail to warning when MS UEFI CA not found in DB
* lib: fwts_uefi: add BMC device path define
* uefidump: add dumping the BMC device path
* uefibootpath: add test for the BMC device path
* lib: fwts_uefi: add the URI device path define
* uefibootpath: add test for the URI device path
* uefidump: add dumping for the URI device path
* lib: fwts_uefi: add the UFS device path define
* uefidump: add dumping for the UFS device path
* uefibootpath: add test for the UFS device path
= Fixed Bugs =
* dmi: dmicheck: fix SMBIOS issues on aarch64 systems
* acpidump: add missing reserved fields to MADT structures
* cpufreq: the calibration is taking a long time, make it faster
* acpi: tcpa: replace tab with spaces to fix formatting alignment
More Information:
http://fwts.ubuntu.com/release/fwts-V15.11.00.tar.gz
https://launchpad.net/~firmware-testing-team/+archive/ubuntu/ppa-fwts-stable
https://wiki.ubuntu.com/FirmwareTestSuite/ReleaseNotes/15.11.00
https://launchpad.net/ubuntu/+source/fwts
Reversing UEFI firmware
Jethro Beekman, author of UEFIreverse, has an excellent blog post on UEFI reversing, showing how he uses these tools!
https://jbeekman.nl/blog/2015/03/reverse-engineering-uefi-firmware/
Teddy Reed on bypassing Linux Secure Boot
Teddy Reed has a second article on UEFI, MinnowboardMax and Linux! This one is called “Minnowboard Max: Booting Linux Securely”, and talks about how the Linux shim is used, and enumerates the various ways this boot security can be bypassed.
[…] I say ‘more-or-less’ because there are tons of places where the verification can be subverted. Unfortunately, if you start examining the implementation and configuration details of the streamlined Secure Boot support, you’ll find plenty of bypasses. Let’s talk briefly about each bypass and conclude with a simple way to use Secure Boot and enforce a signed kernel execution on Ubuntu. To be clear, there are no vulnerabilities here as there is no documented intention to boot Linux securely (e.g., BUG/1401532), only to support a Secure Boot and boot Linux. […]
http://prosauce.org/blog/2015/10/31/booting-linux-securely
CHIPSEC 1.2.2 released!
After nearly a quarter without an update, CHIPSEC 1.2.2 has been released!!
This release includes multiple new VMM tests — including new fuzzers — hinted at DEF CON and elsewhere, a VENOM test, some S3 tests, support for more Intel CPUs, as well as a bunch of new/updated features:
NEW modules:
* tools.vmm.cpuid_fuzz to test CPUID instruction emulation by VMMs
* tools.vmm.iofuzz to test port I/O emulation by VMMs
* tools.vmm.msr_fuzz to test CPU Model Specific Registers (MSR) emulation by VMMs
* tools.vmm.pcie_fuzz to test PCIe device memory-mapped I/O (MMIO) and I/O ranges emulation by VMMs
* tools.vmm.pcie_overlap_fuzz to test handling of overlapping PCIe device MMIO ranges by VMMs
* tools.vmm.venom to test for VENOM vulnerability
Updated modules:
* tools.smm.smm_ptr to perform exhaustive fuzzing of SMI handler for insufficient input validation pointer vulnerabilities
* smm_dma to remove TSEGMB 8MB alignment check and to use XML “controls”. Please recheck failures in smm_dma.py with the new version.
* common.bios_smi, common.spi_lock, and common.bios_wp to use XML “controls”
* common.uefi.s3bootscript which automatically tests protections of UEFI S3 Resume Boot Script table
* tools.uefi.s3script_modify which allows further manual testing of protections of UEFI S3 Resume Boot Script table
NEW functionality:
* hal.cpu component to access x86 CPU functionality. Removed hal.cr which merged to hal.cpu
* hipsec_util cpu utility, removed chipsec_util cr
* S3 boot script opcodes encoding functionality in hal.uefi_platform
* hal.iommu, cfg/iommu.xml and chipsec_util iommu to access IOMMU/VT-d hardware
* chipsec_util io list to list predefined I/O BARs
* support for Broadwell, Skylake, IvyTown, Jaketown and Haswell Server CPU families
* ability to define I/O BARs in XML configuration using register attriute similarly to MMIO BARs
* UEFI firmware volume assembling functionality in hal.uefi
* Implemented alloc_phys_mem in EFI helper
See the full readme on the github page, which also includes short lists of bugfixes and known-issues:
https://github.com/chipsec/chipsec
If you haven’t been following current security research by Intel’s ATR team, who produces CHIPSEC, watch this video to see why you need to run this new version of CHIPSEC on any machine — after reading CHIPSEC’s warning.txt first — that runs a VMM:
[Hopefully we’ll see Intel LUV team add this release to their project, including LUV-live, soon. There has been a recent patch to LUV that may fix CHIPSEC’s usage in LUV-live, a second important reason to update your LUV-live images.]
UEFI Forum’s new FW/OS Forum
The UEFI Forum has created a new mailing list for discussion of UEFI with OS software:
https://twitter.com/Intel_UEFI/status/661623355368312832
“The FW/OS Forum is a free public forum focused on firmware and operating system (OS) integration. Developers are invited to openly discuss challenges and collaboratively identify fixes. The UEFI Forum created the FW/OS Forum in response to community input, which called for a centralized resource dedicated to troubleshooting UEFI firmware issues encountered when working with any OS. The UEFI Forum is committed to making these community discussion and feedback mechanisms effective for all users. Considering, you may see changes based on usability enhancements. FW/OS Forum members are asked to refrain from sharing any non-public information regarding specification or test tool work that is still in development, as well as any company-specific IP or UEFI Forum-specific IP. Additionally, the FW/OS Forum should not be considered a venue for bug tracking. Firmware integration issues raised within the FW/OS Forum will not be considered as formal bug fix requests; however, the information captured may be considered in future specification updates.”
UEFI 2.5 Platform Recovery feature appearing in Tianocore
Ruiyu Ni of Intel has posted an 12-part patch addding UEFI 2.5’s Platform Recovery feature to the public Tianocore EDK2 trunk.
Amongst the features of UEFI 2.5, the last public release of UEFI from the UEFI Forum, was #1227 “UEFI.Next feature – Platform recovery“. Load up the multi-thousand page UEFI 2.5 specification, with a PDF viewer with good search abilities, to find all the locations in the spec which Platform Recovery impacts. A good place to start would be around page 119, the OsRecovery#### and PlatformRecovery#### variables that’re new to UEFI 2.5.
Given that the patch includes a question from Intel asked HP: “Could you please check my patch to see whether it can meet your real requirement?“, it appears that HP already has an existing implementation of this, perhaps already publicly available, probably separate from the Tianocore implementation, like they did with HTTP Boot. I’m not sure of other vendors with existing UEFI 2.5 Platform Recovery support.
Given UEFI capsule updates can add new features, your next firmware update may include this feature; is your organization ready to deal with UEFI 2.5 Platform Recovery support appearing in the near future? I’m not ready. I don’t understand what this feature really means, in terms of system impact. Earlier (not in this patch), there was a LOT of new code dealing with recovery in drivers. I don’t now know how to test this feature yet in Tianocore. Are there any new tools involved with this feature, for sysadmins to use? How do I test if this feature is working in a specific driver, or in the entire system? Where are some test scripts that exercise the feature? If someone has any more pointers to using this new feature, please add a Comment to this post (see left), thanks!
Subject: [Patch 00/11] Add Platform Recovery support
OS Recovery will be added later.
Ruiyu Ni (11):
MdePkg: Add Platform Recovery definitions.
MdeModulePkg: Add Bm prefix for internal functions
MdeModulePkg: Use BmCharToUint in BmIsKeyOptionVariable
MdeModulePkg: Use BM_OPTION_NAME_LEN instead of sizeof L”Boot####”
MdeModulePkg: Use BmForEachVariable to collect all key options
MdeModulePkg: Support to expand File device path
MdeModulePkg: Add Platform recovery support
MdeModulePkg: Add missing PrintLib to BdsDxe.inf
MdeModulePkg: Use UefiSpec.h defined macro to replace L”xxx” string
MdeModulePkg: Add PlatformRecovery#### pointing to default file path
MdeModulePkg: Enable PlatformRecovery in BdsDxe driver
MdeModulePkg/Include/Library/UefiBootManagerLib.h | 1 +
MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c | 76 ++++
MdeModulePkg/Library/UefiBootManagerLib/BmHotkey.c | 181 +++++—-
…/Library/UefiBootManagerLib/BmLoadOption.c | 155 +++++–
MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c | 26 ++
…/Library/UefiBootManagerLib/InternalBm.h | 30 +-
…/UefiBootManagerLib/UefiBootManagerLib.inf | 1 +
MdeModulePkg/Universal/BdsDxe/Bds.h | 3 –
MdeModulePkg/Universal/BdsDxe/BdsDxe.inf | 1 +
MdeModulePkg/Universal/BdsDxe/BdsEntry.c | 447 ++++++—————
MdePkg/Include/Uefi/UefiSpec.h | 1 +
11 files changed, 474 insertions(+), 448 deletions(-)
More Information:
https://lists.01.org/mailman/listinfo/edk2-devel
Peter Jones on Linux UEFI shim
Peter Jones of Red Hat has an interesting post on Linux, UEFI, Secure Boot, and Linux shim maintenance.
If you use Linux and it’s UEFI Secure Boot shim, you may want to read this.
http://blog.uncooperative.org/blog/2015/11/02/shim-info/
http://blog.uncooperative.org/shim-info-2015-11-02.txt.asc
ExtremeGTX’s Win32 UEFI Library
ExtremeGTX has created a new ‘hello world’ sample for UEFI developers on github. It is currently is centered around boot manager features. If you are new to UEFI application development, and want to learn how to do Windows-centric ‘OS-present’ code to talk to UEFI, this is another sample you may want to look at. It is new, so perhaps give the author some more time to add more to the library.
ExtemeGTX: If you are reading this, please consider upgrading to a newer version of Microsoft Visual C++, I think you’re still using something from a pre-Y2K era, which generates ugly template code, not to mention decades of bugs and newer features to help you write better code, the whole point of an IDE. And fewer conversion pain for others that try to compile your code with a copy of Visual Studio 201x. Thank you!
https://github.com/ExtremeGTX/Win32-UEFILibrary
Another UEFI Hello World sample project
There’s a new hello world sample on using UEFI on Github, MyPkg by KurtQiao. The GPL-licensed sample code does a variety of things to experiment with UEFI:
* AHCI: sample how to manipulate AHCI mmio issue HDD identify cmd and ODD eject cmd.
* ctest: a uefi sample import c language.
* HddId: sample how to identify HDD data,support both AHCI and IDE mode.
* HiiMenu: sample how to use uefi HII.
* bootmgr: sample to manipulate UEFI variables, show/set BootOrder, show Boot####, BootCurrent.
* GPT: sample to read disk LBA1 to check GPT signature.
* 2048: small game in UEFI shell
* pwcyle utility that shutdown and RTC wakeup, support both DOS version and UEFI version, by different build.
This is a good starting point for UEFI beginners to start learning about UEFI, beyond just working with the single hello world app in Tianocore, and the rest of the live implementation code. It is similar to the “Bare Metal Examples” project, in this regard. As well, the Intel SSG UEFI training courseware lab samples are also good for this, though mostly targetting an IHV/OEM audience.
Hack.lu 2015 Radare2 firmware hacking workshop materials
There was a Radare2 workshop at HACK.LU 2015, which included firmware targets. Check out the github’s top-level readme, Chapter 2 on Firmware. There are some UEFI-based demos in the Github project, as well.
https://github.com/XVilka/hacklu
http://archive.hack.lu/2015/
Click to access radare2-workshop-slides.pdf
http://archive.hack.lu/2015/radare2-workshop/
http://2015.hack.lu/archive/2015/radare2-workshop/vm/
Laszlo’s OVMF SMM patch status
Laszlo Ersek of Red Hat has a huge patch to Tianocore, which adds SMM to OVMF, and just posted a detailed status update to the EDK2-devel mailing list, The current test results of patch look impressive! Pretend the following table is using a fixed font:
accel bits guest OS OS boots efibootmgr works on S3 resume
—– —- ————— ——– ——————- ———
TCG 32 Fedlet 20141209 pass[1] BSP and AP pass
TCG 64 F21 XFCE LiveCD pass[1] BSP and AP fail[2]
KVM 32 Fedlet 20141209 pass BSP and AP pass
KVM 64 F21 XFCE LiveCD pass BSP and AP fail[2]
KVM 64 Windows 8.1 pass n/a fail[2]
I’ve excerpted the key items from the TODO section of the status report: 🙂
* TODO:
– celebrate a bit this weekend (look at that “OS boots” column!)
– celebrate some more?
Full status report (including most of the details, and the omitted footnotes listed above):
http://article.gmane.org/gmane.comp.bios.edk2.devel/3357
(Also note that the EDK2-devel mailing list, which recently moved from SourceForge.net to Intel’s 01.org, is now hosted on Gmane under the gmane.bios.edk2 namespace. The previous SourceForge list is listed under the gmane.bios.tianocore namespace.)
Lenovo support notice on UEFI memory usage
This is a nice of an OEM to make their support articles available, usually they are hard to find.
UEFI’s A Priori File
UEFI has an “A Priori File”, which lets vendors list the explicit drivers to load, to override traditional hardware bus enumeration. This is a security issue: if an attacker was able to modify this, then the game is over, their drivers are loaded. From a Tianocore FAQ:
There is another method called an a priori file. There can be one per Firmware volume. This will tell the dispatcher what order to dispatch list drivers in the order they need to dispatch them. This is a manual order. It does not need to be in any specific place in the FV. If it in the FV the dispatcher will find it.
Bluntly, I don’ t know the right way to efficiently search for A Priori Files on UEFI systems, probably using GUIDs via UEFI Tool. EDK-I — but not, apparently, EDK-II — had a GenApriorFile tool. If someone knows how, please speak up. Anyway, in an ideal world, you’ll be searching all of your firmware volumes for an A Priori File …as well as the UEFI Shell’s ‘autoexec.bat’ equivalent: startup.nsh, the latter may be anywhere in the path.
http://tianocore.sourceforge.net/wiki/EDK_II_FAQ#Is_an_a_priori_file_checked_first.3F
Firmware Security 
You must be logged in to post a comment.