Alex Hung of Canonical has announced the 16.05.01 release of FWTS, the FirmWare Test Suite.
There are new ACPI and IPMI and TCG OVAL and Linux device-tree tests. In addition to new features, there’s an even larger list of bugfixes for most classes (UEFI, BIOS, ACPI, etc.) of tools, not excerpted below, see the full announcement for those.
* acpi: add MSCT table sanity check
* acpi: add EINJ table sanity check
* ACPICA: Update to version 20160318 (LP: #1559312)
* Introduce olog scan, to check OPAL msglog.
* Introduce IPMI BMC Info
* devicetree: add infrastructure for device-tree tests
* devicetree/dt_sysinfo: Add device tree system information tests
* devicetree/dt_base: Add base device-tree validity checks
* debian/control: change depends on libjson0-dev to libjson-c-dev
* auto-packager: mkpackage.sh: add yakkety and remove vivid
* debian/control: add back libjson0-dev for precise
Eric Dong of Intel has updated UEFI’s TCG OVAL support, used with SEDs, how the UEFI-based system will work with the locked SEDs, when the user has no valid password:
[Patch] SecurityPkg OpalPasswordDxe: Enhance input password process.
Enhance the input password process, when device in unlock status and user press ESC, shutdown the device. If user reach the max try number, shutdown the device.
+ L”Confirm: Not unlock device and continue boot?.”,
+ L”Press ENTER to confirm, Press Esc to input password”,
+ L”Warning: system in unkown status, must shutdown!”,
+ L”Press ENTER to shutdown.”,
– L”Opal password retry count is expired. Keep lock and continue boot.”,
+ L”Opal password retry count exceeds the limit. Must shutdown!”,
L”Press ENTER to continue”,
For more information, see the patch on the edk2-devel list:
Eric Dong of Intel has submitted an 8-part patch to enable TCG OPAL password support in UEFI:
Enable Opal password solution: These patches used to enable opal password solution in BIOS. Opal feature defined in TCG storage Opal spec. This opal solution is a sample driver shows how to use opal feature in bios. It enables user to config opal feature in the setup page and popup dialog to let user unlock device in boot phase. It auto unlock opal device in S3 resume phase.
MdePkg: Add definition for TCG Storage Core and Opal specs.
SecurityPkg: TcgStorageCoreLib: Add TCG storage core library.
SecurityPkg: TcgStorageOpalLib: Add TCG storage opal library.
SecurityPkg: OpalPasswordSupportLib: Add Opal password support
SecurityPkg: Add library header file definition to package.
SecurityPkg: OpalPasswordDxe: Add Opal password dxe driver.
SecurityPkg: OpalPasswordSmm: Add Opal password Smm driver.
SecurityPkg: Enable Opal password solution build in Security package
39 files changed, 21524 insertions(+)
For more information:
The presentation PDFs (no A/V) are now available for the NVMe Flash Memory Summit, as well as NVME’s presentations from IDF.
The Flash Memory Summit presentations ZIP includes all of the PDFs of that conference, including one on NVMe security, discussing OVAL, Self Encrypting Drives (SEDs), integration with Trustworthy Computing standards, among other things.
[I posted this blog entry a few hours ago, then immediately deleted it, after noticing that that CVE was listed as 2014, not 2015, and thought my search was invalid. But I just re-checked, and the CVE is dated yesterday, 2015-06-28. So I was wrong to delete the post.]
There’s a new NIST SCAP CVE for IBM UEFI for some systems, involving remote attackers. An excerpt of the data is listed below, see below URLs for full release in case you have one of these IBM systems.
Vulnerability Summary for CVE-2014-4768
Original release date: 06/28/2015
Last revised: 06/29/2015
“IBM UEFI on Flex System x880 X6, System x3850 X6, and System x3950 X6 devices allows remote authenticated users to cause an unspecified temporary denial of service by using privileged access to enable a legacy boot mode.”
PS: Related to firmware and SCAP, but unrelated to this specific CVE: AFAICT, nobody has SCAP OVAL definitions for UEFI, and no SCAP tools look for UEFI issues. Once SCAP has UEFI OVAL definitions, apps like CHIPSEC and Copernicus can start issueing SCAP reports with this metadata, so firmware bugs can be found with SCAP security tools, instead of full-text-search luck. So AFAICT there is no way to use SCAP to properly look for firmware issues, only full-text search and hope that that “UEFI” or “BIOS” or “firmware” are included. I wish (Intel, ARM, UEFI Forum, OpenPOWER, etc.) and other vendors and trade groups who maintain firmware code should also maintain their SCAP metadata, to help keep enterprises more secure. The ecosystem needs more help looking for hardware and firmware-level bugs, they know how to look for kernelspace and userland bugs.