Virt-Manager updated with UEFI (OVMF/AVMF) support

Virt-Manager, as of 1.2, has support for UEFI’s OVMF/AVMF format!

http://www.phoronix.com/scan.php?page=news_item&px=UEFI-OVMF-Virt-Manager-1.2
http://blog.wikichoon.com/2016/01/uefi-support-in-virt-install-and-virt.html
http://www.phoronix.com/scan.php?page=news_item&px=Virt-Manager-1.2-Released
https://www.redhat.com/archives/virt-tools-list/2015-May/msg00010.html
https://virt-manager.org/

I missed this news, but luckily Phoronix did not…

BTW, Virt-Manager is a SPICE client, and UEFI has some SPICE support. I don’t know what that means, I’ve been meaning to learn… 🙂 There is information on this in the below OVMF whitepaper:

http://www.spice-space.org/
http://www.linux-kvm.org/downloads/lersek/ovmf-whitepaper-c770f8c.txt

RISC-V/LowRISC update

The recent RISC-V workshop is over, presentations are online, videos are not yet online:

http://riscv.org/workshop-jan2016.html
http://riscv.org/

RISC-V and coreboot:

Click to access Tues1345%20riscvcoreboot.pdf

RISC-V and UEFI:

Click to access Tues1415%20RISC-V%20and%20UEFI.pdf

There is some post-workshop coverage here:
https://blog.riscv.org/2016/01/3rd-risc-v-workshop-presentations-breakouts/
http://www.lowrisc.org/blog/2016/01/third-risc-v-workshop-day-one/
http://www.lowrisc.org/blog/2016/01/third-risc-v-workshop-day-two/

Why I will be using RISC-V in my next chip


http://www.eetimes.com/document.asp?doc_id=1328620&

LowRISC, a related project to RISC-V is also making progress. From the below EE Times article:

“The LowRISC project at the University of Cambridge is attracting interest as the likely first source of real development hardware. The team which includes members of the Raspberry Pi project hopes to have first silicon this year and plans to make development boards available in 2017, likely for $50-100.”

http://www.lowrisc.org/

http://www.eetimes.com/document.asp?doc_id=1328620&

I missed this news, it is interesting to see Google, HP, and Oracle getting involved with RISC-V.

http://www.eetimes.com/document.asp?doc_id=1328561&

 

U-Boot and UEFI at Seattle Hardware Startups event

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!

http://www.meetup.com/Seattle-Hardware-Startups/events/227429885/

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.

Speakers:

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.

Adam
PS: Did you know that January 15th is Hardware Freedom Day?
http://www.hardwarefreedomday.org/main/about.html

Firmware and RISC-V workshop

At the 3rd RISC-V Workshop, there have been presentations by coreboot and UEFI. The below blog has some notes on these presentations:

http://riscv.org/workshop-jan2016.html
http://www.lowrisc.org/blog/2016/01/third-risc-v-workshop-day-one/

Apparently, someone is porting UEFI to RISC-V. I wonder what company is funding/doing it??

BITS: new network-enabled release (and new mailing list)

Burt Triplett of Intel has announced the version 2070 release of BITS (BIOS Implementation Test Suite). The main new feature is network support, but also includes new UEFI and ACPI and Python features, better command line features, and other new features. I’ve just excerpted the first paragraph of the networking-centric portion of the announcement below, there are a lot of implementation caveats to read. See the full announcement for the list of features and bugfixes.

Note that there is also a new BITS mailing list, see below URL for ‘first post’ message in the archives:

BITS on EFI now supports TCP networking, using the Python socket module and various modules built atop it.  On EFI systems that provide `EFI_IP4_CONFIG_PROTOCOL` and `EFI_TCP4_SERVICE_BINDING_PROTOCOL`, we implement a `_socket` module in Python with support for TCP sockets over IPv4.  We then include Python’s higher-level socket module that runs on top of `_socket`.

https://lists.01.org/mailman/listinfo/bits
https://lists.01.org/pipermail/bits/2016-January/000000.html
http://biosbits.org/news/bits-2070/
http://biosbits.org/downloads/bits-2070.zip
https://github.com/biosbits/bits

screenshot-taking UEFI DXE driver

Nikolaj has written a UEFI DXE driver that takes screenshots. In addition to a useful new UEFI tool (since taking pre-OS screenshots outside of a VMM are often a PITA), the article is a nice introduction to EFI development. Attackers can use techniques like this to capture display activity in the background, just like they do in OS-level malware.

UEFI DXE driver to take screenshots from GOP-compatible graphic console: This DXE driver tries to register keyboard shortcut (LCtrl + LAlt + F12) handler for all text input devices. The handler tries to find a writable FS, enumerates all GOP-capable video devices, takes screenshots from them and saves the result as PNG files on that writable FS. The main goal is to be able to make BIOS Setup screenshots for systems without serial console redirection support, but it can also be used to take screenshot from UEFI shell, UEFI apps and UEFI bootloaders.

See the readme and the blog post (in Russian) for more information:

https://github.com/NikolajSchlej/CrScreenshotDxe

http://habrahabr.ru/post/274463/

http://translate.google.com/translate?hl=en&sl=ru&tl=en&u=http%3A%2F%2Fhabrahabr.ru%2Fpost%2F274463%2F&sandbox=1

FreeBSD’s 2015 UEFI update

From the FreeBSD Foundation’s December 2015 (end-of-year) update, in summarizing their development efforts, they mention firmware (as well as improvements to x86 hardware support, and AArch64 support):

 

UEFI and secure boot: FreeBSD’s UEFI boot support needs to interoperate with many different EFI firmware implementations, and it’s only after broad testing that we were able to identify some incompatibilities. Through effort from Foundation staff and from volunteers in the FreeBSD community we’ve fixed UEFI boot on a variety of hardware and virtualization platforms, including Apple Macbook and Mac Pro computers and VirtualBox and VMware. These improvements will be available in FreeBSD 11.0 and 10.3. We also started working on support for secure boot. To date we’ve been working on individual tools — the uefisign(8) utility to add Authenticode signatures to EFI files, and the sysutils/pesign, sysutils/sbsigntool and sysutils/shim ports. Next year we’ll integrate these components into a broader secure boot implementation.

More information: click on the tiny-URL PDF in the below tweet:

https://wiki.freebsd.org/UEFI

https://wiki.freebsd.org/SecureBoot

Matthew on x86 boot security

Apple has a lot of work to do, but they just hired LegbaCore, so they should be able to improve.

Linux has a lot of work to do, to catch up to Windows. Luckily there are people like Matthew working on it.

OEMs/Intel has a lot of work to do: they should be working to build the Stateless Laptop that ITL has proposed.

http://mjg59.dreamwidth.org/39339.html

Brainfuck for EFI

Kirn Gill has ported the Brainfuck language’s interpreter to UEFI!

https://github.com/segin/efibrainfuck

https://en.wikipedia.org/wiki/Brainfuck

http://segin-rr.blogspot.com/

So we have another language option for pre-OS scripting. And something else to look for when searching the UEFI’s ESP (EFI System Partition) for security threats: also look for Brainfuck scripts (and the interpreter), in addition to Python, Lua, Ruby, etc. scripts.

It is built with GNU-EFI, not Tianocore’s EDK-II.

Video/Slides for Jethro’s CCC UEFIreverse talk!

Yesterday I mentioned Jethro Beekman had a lecture at CCC on UEFIreverse, but was not sure about video. Video/slides are now available!

UEFIreverse lecture at CCC!

Click to access uefireverse.pdf

https://jbeekman.nl/research/

https://streaming.media.ccc.de/32c3/relive/7245/

UEFI Firmware Parser now in Cheese Shop

The other day I noticed some Github activity for Teddy Reed’s UEFI Firmware Parser, but didn’t notice any formal new announcement. It appears I was not looking in the right place. The parser is now in the official Python Cheese Shop! And it is named “uefi_firmware”, not UEFI Firmware Parser, that explains that comment in the comment log. 🙂 It’ll be nice to have this tool more easily-available in Python. I hope the next time the UEFI Forum updates it’s UEFI port of CPython, they add this module to the UEFI port.

https://pypi.python.org/pypi/uefi_firmware

UEFI Firmware Parser updated

new UEFI support in Citrix 7.7

One of the new features in this release:

Support for UEFI pre-boot environments. This enables you to stream at startup time using gigabit network speeds, so users experience faster startups, and to use disks over 2 TB.

https://docs.citrix.com/en-us/provisioning/7-7/pvs-new.html

I’m unclear of the specifics. What does ‘UEFI pre-boot environments’ mean? Does this mean OVMF support or something else? How does this help my startup time using gigabit network speeds, does this mean UEFI pre-OS network functionality is used, or something else?
Where is the security documentation for Citrix sysadmins, clarifying pre-OS issues if they’re being added to the stack for the first time? (For that matter, I’ve not found any good docs on this latter topic by any VMM vendor.)

 

EFI app port added to U-Boot!

On December 22th, Alexander Graf of SuSE posted a patch to the U-Boot list, adding EFI payload/application support to U-Boot!

 

This is my Christmas present for my openSUSE friends :).

U-Boot is a great project for embedded devices. However, convincing everyone involved that only for “a few oddball ARM devices” we need to support different configuration formats from grub2 when all other platforms (PPC, System Z, x86) are standardized on a single format is a nightmare.

So we started to explore alternatives. At first, people tried to get grub2 running using the u-boot api interface. However, FWIW that one doesn’t support relocations, so you need to know where to link grub2 to at compile time. It also seems to be broken more often than not. And on top of it all, it’s a one-off interface, so yet another thing to maintain.

That led to a nifty idea. What if we can just implement the EFI application protocol on top of U-Boot? Then we could compile a single grub2 binary for uEFI based systems and U-Boot based systems and as soon as that one’s loaded, everything looks and feels (almost) the same.

This patch set is the result of pursuing this endeavor.

  – I am successfully able to run grub2 and Linux EFI binaries with this code.
  – When enabled, the resulting U-Boot binary only grows by ~10kb, so it’s very light weight.
  – It works on 32bit ARM and AArch64.
  – All storage devices are directly accessible
  – No runtime services (all calls return unimplemented)
  – No EFI variables

Of course, there are still a few things one could do on top:

  – Implement removable media booting (search for /efi/boot/boota{a64,rm}.efi)
  – Improve disk media detection (don’t scan, use what information we have)
  – Add EFI variable support using NVRAM
  – Add GFX support
  – Make EFI Shell work 😉

But so far, I’m very happy with the state of the patches. They completely eliminate potential arguments against U-Boot internally and give users the chance to run with the same level of comfort on all firmware types.

  disk/part.c: Expose a list of available block drivers
  include/efi_api.h: Add more detailed API definitions
  efi_loader: Add PE image loader
  efi_loader: Add boot time services
  efi_loader: Add console interface
  efi_loader: Add runtime services
  efi_loader: Add disk interfaces
  efi_loader: Add “bootefi” command
  efi_loader: hook up in build environment

More information:
http://lists.denx.de/pipermail/u-boot/2015-December/239054.html

Licensing will be interesting. Tianocore demands BSD, U-Boot prefers GPL.

The first person who gets CHIPSEC to work under this patch, please speak up!

VirtualBox hardened loader

https://twitter.com/hFireF0X/status/679926803364982789
http://www.kernelmode.info/forum/viewtopic.php?f=11&p=27460#p27460
https://github.com/hfiref0x/VBoxHardenedLoader
http://www.kernelmode.info/forum/viewtopic.php?f=11&t=3478

“VirtualBox Hardened VM detection mitigation loader: VBoxAntiVMDetectHardened is a complex of methods implemented to reduce VM detection possibilities of the common malware.”

Interesting, there are UEFI patches for this, as well!

New UEFI Stall and Reset System tools

theChiChen has created a new Github project with some hello-world-level UEFI applications. Besides a few Hello Worlds, there is are Stall and ResetSystem commands. These are built with EDK-II/Tianocore, not GNU-EFI toolchain.

https://github.com/theChiChen/UEFI_SHELL_Utilities
https://github.com/theChiChen/UEFI_SHELL_Utilities/blob/master/ChiChenPkg/Application/Stall/Stall.c
https://github.com/theChiChen/UEFI_SHELL_Utilities/blob/master/ChiChenPkg/Application/ResetSystem/ResetSystem.c

One of these days, I need to create a list of all these hello-world apps for UEFI and other firmware targets. There used to be only a handful, now there’s a few dozen..

UEFI gets more IPMI 2.0 features

Daocheng Bu of Intel added new IPMI libraries to UEFI’s public EDK-I dev kit. Earlier, IPMI 2.0 definitions were added, now a library to support a generic PIMI submitt command has been added:

Update Ipmi2.0 definitions header file and MdeModulePkg.dsc
file for Ipmi libraries. Add Ipmi realted libraries to support
generic Ipmi submit command. Also add Ppi/Protocol definitions
that will be produced by Ipmi Peim and drivers.

  MdePkg: Update Ipmi2.0 definitions header file.
  MdeModulePkg: Add IpmiLib and Ppi/Protocol header file.
  MdeModulePkg: Add BaseIpmiLib Null Library Instance.
  MdeModulePkg: Add PeiIpmiLibIpmiPpi Library Instance.
  MdeModulePkg: Add DxeIpmiLibIpmiProtocol Library Instance.
  MdeModulePkg: Add SmmIpmiLibSmmIpmiProtocol Library Instance.
  MdeModulePkg: Update MdeModulePkg.dsc file for IpmiLib.

   18 files changed, 803 insertions(+), 135 deletions(-)

More info: see the patch on the edk2-devel list:
https://lists.01.org/mailman/listinfo/edk2-devel

New UEFI-patched GRUB Legacy

There’s a new GRUB Legacy build on Github, which has some UEFI patches, called grub0.97-patched. The forker has a strong opinion towards GRUB 2… 🙂

 

“A fork of GRUB 0.97 (aka Legacy), included several patches for UEFI, RAID, GPT, … I created this repo to archive the last version of GRUB Legacy and their community-made patches that were scattered all over the Internet. GRUB development team has deleted the repo of GRUB Legacy, citing that GRUB 2 is the future. In fact, their future is shit.”

https://github.com/annguyenfoss/grub0.97-patched

https://github.com/annguyenfoss/grub0.97-patched/commits/master