Uncategorized

Testing SMM with QEMU, KVM and libvirt

Laszlo Ersek has created a new document that shows how to test SMM using UEFI’s OVMF. Great information!

I’ve added the following article to the TianoCore wiki[1]. It should help both Windows and Linux desktop users build a KVM test machine / environment that closely resembles mine. Such an environment is useful for testing and regression-testing new MP and SMM features and bugfixes. The initial setup is not short, but once you got it up and running, it’s very simple to rebuild OVMF with the edk2 changes, install the firmware binary in the right place (see the article) and then click the Play button on the Fedora 25 and Windows 10 guests, to see the changes in action. If you have smaller updates or structural reorgs for the document, there’s no need to ask me, just go ahead and do them. If some significant information is missing that you’d like me to add, I think I’d prefer new TianoCore BZs at this time (Product: Tianocore Feature Requests, Component: Web Content, Assignee: yours truly). I don’t know when I’ll have time again to dig into this.
[1]https://github.com/tianocore/tianocore.github.io/wiki/Testing-SMM-with-QEMU,-KVM-and-libvirt

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

Standard
Uncategorized

OpenCIT 2.2 released

Adolfo V Aguayo of Intel announced the version 2.2 release of OpenCIT.

New Features in 2.2:
– TPM 2.0 support.
   + Added support for platform and asset tag attestation of Linux and Windows hosts with TPM 2.0.
   + Support attestation of either SHA1 or SHA256 PCR banks on TPM 2.0.
   + Ubuntu 16.04 and RHEL 7.2, 7.3 (SHA1 and SHA256), Windows Server 2012 and Hyper-V Server 2012 (SHA1) are supported with TPM 2.0
– All the certificates and hashing algorithms used in CIT are upgraded to use SHA256.  SHA1 has been deprecated and will no longer be used.
– CIT Attestation Service UI has been updated to allow the user to select either the SHA1 or SHA256 PCR bank for Attestation of TPM 2.0 hosts.
    + The CIT  Attestation Service will automatically choose the strongest available algorithm for attestation (SHA1 for TPM 1.2, and SHA256 for TPM 2.0)
– CIT Attestation Service UI Whitelist tab no longer requires the user to select PCRs when whitelisting, and will automatically choose the PCRs to use based on the host OS and TPM version.  This is done to reduce confusion due to differing behaviors between TPM 1.2 and TPM 2.0 PCR usages.
– Additional changes made to support TPM 2.0:
    + Linux hosts with TPM 2.0 will now utilize TPM2.0-TSS (TPM 2.0 Software Stack) and TPM2.0-tools instead of the legacy trousers and tpm-tools packages. The new TSS2 and TPM2.0-tools are packaged with the CIT Trust Agent installer.
    + TPM 2.0 Windows hosts use TSS.MSR (The TPM Software Stack from Microsoft Research) PCPTool.
    + TPM 1.2 hosts will continue to use the legacy TSS stack (trousers) and tpm-tools components.

For more information, see the full announcement on the oat-devel@lists.01.org mailing list.

https://github.com/opencit
https://01.org/opencit

Standard
Uncategorized

Peter Jones on Secure Boot failures and mitigations

I just now came across a blog post written by Peter Jones from LAST MONTH on that “Microsoft Secure Boot Golden Key” news reports that is worth reading. Peter owns the Linux shim, so he knows a bit about UEFI’s boot process.

https://blog.uncooperative.org/blog/2016/08/18/secure-boot-failures-and-mitigation/

Especially because I’ve had nearly nothing useful in this blog on this post:

https://firmwaresecurity.com/2016/08/18/more-on-microsoft-uefi-secure-boot-golden-key-news/

 

https://firmwaresecurity.com/2016/08/11/microsoft-uefi-secure-boot-key-problem/

Also note other articles in Peter’s blog: he makes regular canary posts about the state of his Shim code. I wish all of the boot/firmware code required all contributes to have canaries!

Standard
Uncategorized

Steven Ellis: firmware updating on Linux

Steven Ellis of Red Hat has a new article on OpenSource.com on updating firmware and UEFI, with lots of good stuff to read. He mentions his next article will be on the topic of patching SSD firmware, which sounds very interesting. Spoiler alert: I’m exerpting his Recommendations from the end of the post:

[…] In this article, I’ll walk through my recent firmware update on Linux, and I’ll share a few recommendations based on that experience. […]
Recommendations:
* More vendors should allow UEFI BIOS updates directly from the BIOS-style interface. UEFI shell command-line isn’t for the casual user.
* If your vendor supplies a bootable image, try to use that first.
* Investigate what supported tools are available, but consider using a live image for patching. I’m somewhat wary of tools that build and install their own kernel modules.
* Assist projects—like flashrom—to avoid these issues in the future.
[…]

https://opensource.com/life/16/8/almost-open-bios-and-firmware-update-tips-linux-users

Standard
Uncategorized

Firmware Mini-Summit announced

Al Stone of Red Hat has announced the next firmware mini-sumit at Linaro Connect, March in Bankok, Thailand. Excerpt of announcement:

Well, it’s that time of year again. If you’re going to be at Linaro Connect [0] in Bangkok, Thailand on the week of 7-11 March 2016, please drop in to the firmware mini-summit to be help Wednesday afternoon (9 March).  The exact time and location at Connect are still to be determined. We’ll have an hour, and so far the topic list is:

   * Update on current status of ACPI patches (PCI, NUMA, CPPC, plans for the next steps)
   * The new FW_OS_Forum mailing list
   * Progress in ACPI compliance testing in FWTS, and future plans
   * _DSD usage yet again
   * Others?

More information:
http://connect.linaro.org
http://lists.mailman.uefi.org/mailman/listinfo/fw_os_forum

Standard
Uncategorized

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.

https://firmwaresecurity.com/2016/01/29/systemd-uefi-and-efivarfs-bricking-concerns/

 

Standard