Uncategorized

Leif on QEMU and USB host device pass-through

Leif has a new blog post on using UEFI with USB pass-through.

[…]”One thing that is unsurprising, but very cool and useful, is that this works well cross-architecture. So you can test that your drivers are truly portable by building (and testing) them for AARCH64, EBC and X64 without having to move around between physical machines.

http://blog.eciton.net/uefi/qemu-usb-passthrough.html

Checkout his previous blog post, on UEFI driver development, as well as older posts on Linaro/ARM/UEFI history.

 

Standard
Uncategorized

CHIPSEC gets QEMU VirtIO device detection

https://github.com/chipsec/chipsec/commits/master

“Just added detection of QEMU VirtIO devices by @mikhailgorobets & @c7zero. Use “chipsec_util.py vmm virtio” command”

https://github.com/chipsec/chipsec
https://github.com/chipsec/chipsec/pull/98

Standard
Uncategorized

AMD Secure Encrypted Virtualization (SEV) patch for Linux kernel

Brijesh Singh of AMD submitted a 28-part patch to the Linux-(kernel,efi,kvm,…) mailing lists, with a patch for the the Linux kernel to support AMD’s Secure Encrypted Virtualization (SEV), which relies on the recent AMD Secure Memory Encryption (SME) patch by Tom Lendacky of AMD. I’m excerpting the intro text from part 1/28:

[RFC PATCH v1 00/28] x86: Secure Encrypted Virtualization (AMD)

This RFC series provides support for AMD’s new Secure Encrypted Virtualization (SEV) feature. This RFC is build upon Secure Memory Encryption (SME) RFC.

SEV is an extension to the AMD-V architecture which supports running multiple VMs under the control of a hypervisor. When enabled, SEV hardware tags all code and data with its VM ASID which indicates which VM the data originated from or is intended for. This tag is kept with the data at all times when inside the SOC, and prevents that data from being used by anyone other than the owner. While the tag protects VM data inside the SOC, AES with 128 bit encryption protects data outside the SOC. When data leaves or enters the SOC, it is encrypted/decrypted respectively by hardware with a key based on the associated tag.

SEV guest VMs have the concept of private and shared memory.  Private memory is encrypted with the  guest-specific key, while shared memory may be encrypted with hypervisor key.  Certain types of memory (namely instruction pages and guest page tables) are always treated as private memory by the hardware. For data memory, SEV guest VMs can choose which pages they would like to be private. The choice is done using the standard CPU page tables using the C-bit, and is fully controlled by the guest. Due to security reasons all the DMA operations inside the  guest must be performed on shared pages (C-bit clear).  Note that since C-bit is only controllable by the guest OS when it is operating in 64-bit or 32-bit PAE mode, in all other modes the SEV hardware forces the C-bit to a 1.

SEV is designed to protect guest VMs from a benign but vulnerable (i.e. not fully malicious) hypervisor. In particular, it reduces the attack surface of guest VMs and can prevent certain types of VM-escape bugs (e.g. hypervisor read-anywhere) from being used to steal guest data.

The RFC series also includes a crypto driver (psp.ko) which communicates with SEV firmware that runs within the AMD secure processor provides a secure key management interfaces. The hypervisor uses this interface to enable SEV for secure guest and perform common hypervisor activities such as launching, running, snapshotting , migrating and debugging a  guest. A new ioctl (KVM_SEV_ISSUE_CMD) is introduced which will enable Qemu to send commands to the SEV firmware during guest life cycle.

The RFC series also includes patches required in guest OS to enable SEV feature. A guest OS can check SEV support by calling KVM_FEATURE cpuid  instruction.

The following links provide additional details:

AMD Memory Encryption whitepaper:

http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2013/12/AMD_Memory_Encryption_Whitepaper_v7-Public.pdf

AMD64 Architecture Programmer’s Manual:
http://support.amd.com/TechDocs/24593.pdf
SME is section 7.10
SEV is section 15.34

Secure Encrypted Virutualization Key Management:
http://support.amd.com/TechDocs/55766_SEV-KM%20API_Spec.pdf

See the full patch for more information.
https://lkml.org/lkml/2016/8/22/960

Standard
Uncategorized

QEMU 2.6.0 released

QEMU 2.6.0 has been released. A few highlights include:

  * Headless support for OpenGL-capable displays via Virgil/virtio-gpu are now available via Spice client.
  * Support for IPMI through internally emulated BMC or an external BMC interface
  * PCIe multi-root support via pxb-pcie bridge, allowing devices to be exposed to guest on specifically-defined NUMA nodes
  * x86: KVM and TCG emulation support for PKU memory protection feature of newer Intel CPUs within guest

http://article.gmane.org/gmane.comp.emulators.qemu/410994
http://wiki.qemu.org/Download
http://wiki.qemu.org/ChangeLog/2.6

Standard
Uncategorized

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

Standard
Uncategorized

FMK QEMU firmware analysis video tutorial

Daniel Miessler points out that Craig Smith has a video tutorial on firmware analysis of QEMU-based systems and FMK.

https://craigsmith.net/episode-12-1-firmware-emulation-with-qemu/

This is episode 12.1, I missed the earlier ones, and it appears there are other firmware-related  episodes to catch up on.

Standard