Tag: qemu

Shell script for Laszlo’s SMM test environment article

~ hucktech ~ Leave a comment

Laszlo Ersek of Red Hat wrote a wiki article on tianocore.org[1], showing how to setup the EDK2 with QEMU/OVMF for testing SMM code using Fedora.

Recently, Alex Floyd of PreOS Security wrote a shell script to codify this wiki article[2].

Laszlo’s wiki is dense, I expect this script will be useful for some UEFI firmware engineers and security researchers.

According to Alex, “some things needed tweaking to get to work, and the Windows portion of the tutorial is not included in the script.”

[1] https://github.com/tianocore/tianocore.github.io/wiki/Testing-SMM-with-QEMU,-KVM-and-libvirt

[2] https://github.com/gencymex/smmtestbuildscript

https://github.com/gencymex/smmtestbuildscript/blob/master/smmtesthost.sh

Leif on QEMU and USB host device pass-through

~ hucktech ~ 1 Comment

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.

 

CHIPSEC gets QEMU VirtIO device detection

~ hucktech ~ Leave a comment

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

AMD Secure Encrypted Virtualization (SEV) patch for Linux kernel

~ hucktech ~ Leave a comment

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

QEMU 2.6.0 released

~ hucktech ~ Leave a comment

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

efitools now available for ARM

~ hucktech ~ Leave a comment

James Bottomley has a few new blog posts, two on efitools availability for ARM, and another on a container model for UEFI.

http://blog.hansenpartnership.com/efitools-for-arm-released/
http://blog.hansenpartnership.com/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. […]

http://blog.hansenpartnership.com/constructing-architecture-emulation-containers/
http://blog.hansenpartnership.com/constructing-architecture-emulation-containers/build-container/

FMK QEMU firmware analysis video tutorial

~ hucktech ~ Leave a comment

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.

SeaBIOS gets TPM2 security

~ hucktech ~ 1 Comment

BIOS was designed in the era of the initial IBM PC, running IBM PC-DOS — when DOS meant Disk Operating System not Denial of Service — back when there was no security in any hardware, firmware, or software designs. 🙂 As  UEFI documentation likes to mention, BIOS has no security, unlike UEFI (well, at least v2, EFI v1 had much less security). But SeaBIOS, the open source BIOS implementation, has had TPMv1 support for BIOS (and ACPI) since 2011, and today it just got TPMv2 support! It appears that initial TPMv1 support was added to SeaBIOS in 2011 by Stefan Berger of IBM, including TPM support for ACPI; excerpt from his patch email:


The following set of patches add TPM and Trusted Computing support to SeaBIOS. In particular the patches add:

– a TPM driver for the Qemu’s TPM TIS emulation (not yet in Qemu git)
– ACPI support for the TPM device (SSDT table)
– ACPI support for measurement logging (TCPA table)
– Support for initialzation of the TPM
– Support for the TCG BIOS extensions (1ah handler [ah = 0xbb]) (used by trusted grub; http://trousers.sourceforge.net/grub.html)
– Static Root of Trusted for Measurement (SRTM) support
– Support for S3 resume (sends command to TPM upon resume)
– TPM-specific menu for controlling aspects of the TPM
– [An optional test suite for the TIS interface]

All implementations necessarily follow specifications.

When all patches are applied the following services are available
– SSDT ACPI table for TPM support
– initialization of the TPM upon VM start and S3 resume
– Static root of trust for measurements (SRTM) that measures (some) data of SeaBIOS in TCPA ACPI table
– 1ah interrupt handler offering APIs for measuring and sending commands to the TPM (trusted grub uses them)
– User menu for controlling aspects of the state of the TPM

Full message:
http://www.seabios.org/pipermail/seabios/2011-April/001609.html
https://lists.gnu.org/archive/html/qemu-devel/2011-08/msg03835.html

Steven has an article on the QEMU wiki on SeaBIOS TPMv1 support. And Stephan has a SeaBIOS-TPM project on Github, I’m unclear how this relates to SeaBIOS source tree:
http://wiki.qemu.org/Features/TPM
https://github.com/stefanberger/seabios-tpm

So, that was the old 2011 TPMv1 news, that I am catching up to…. Today, Stephan has a new TPM2 patch for SeaBIOS, excerpt of announcement:

This series of patches adds TPM 2 support to SeaBIOS in the way previously proposed. TPM 2 support also changes the log entry format, which I have not addressed at all so far, and would append to the end of the series.

  tpm: Extend TPM TIS with TPM 2 support.
  tpm: Factor out tpm_extend
  tpm: Prepare code for TPM 2 functions
  tpm: Implement tpm2_startup and tpm2_s3_resume
  tpm: Implement tpm2_set_timeouts
  tpm: Implement tpm2_prepboot
  tpm: Implement tpm2_extend
  tpm: Implement tpm2_menu
  tpm: Implement TPM 2’s set_failure

Full message:
http://www.seabios.org/mailman/listinfo/seabios

Also search the recent checkins for other interesting TPM checkins, eg, Physical Presence API, etc.

I asked on the SeaBIOS list if there was a security roadmap for me to point to, and what consumer devices have TPM support; Kevin O’Connor replied, mentioning the addition of TPMv2, and:

I’m not aware of any new consumer devices shipping with the support, and I understand that KVM/QEMU have had TPM support for some time already.

I think some Google Chromebooks come with coreboot-based TPM-enabled SeaBIOS, and TPM is used to store developer mode state instead of CMOS. I haven’t found canon spec in ChromeOS site, but there are a few online references such as this:
https://news.ycombinator.com/item?id=9185719

I’m not aware of any new consumer devices shipping with the support. If you have a new system, check with the vendor to see if it supports TPM or not. If your BIOS is not SeaBIOS-based, check if it has TPM support; if not, ask the vendor why not.

It would be interesting for a security researcher to compare the BIOS security measures in currently-available consumer devices, SeaBIOS-based and other BIOS codebases. I am not sure how many different BIOS codebases there are, these days. Perhaps AMI and Phoenix have one, and some OEMs? I should research that more. Ralph Brown: help! 🙂

http://www.seabios.org/

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

~ hucktech ~ Leave a comment

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

KVM Forum 2015 materials available

~ hucktech ~ Leave a comment

[[ UPDATE: WordPress mangles the below URL to Pauolo’s SMM talk. Download the PDF from the linux-kvm.org link below instead. ]]

The KVM Forum recently finished, and their post-conference materials are available, including videos of some of the presentations. There are multiple interesting talks on QEMU and KVM for security researchers. Two talks that jump out to me are:

Securing secure boot: system management mode in KVM and Tiano Core
by Paolo Bonzini

Click to access 03×06-Aspen-Paolo_Bonzini-Securing_secure_boot.pdf

Using IPMI in QEMU
by Corey Minyard

Click to access 03×08-Juniper-Corey_Minyard-UsingIPMIinQEMU.ods.pdf

More Information:
http://www.linux-kvm.org/page/KVM_Forum_2015

ACPI testing with BITS Python

~ hucktech ~ Leave a comment

Recently, Josh Triplett of Intel gave a talk on using BIOS Interface Test Suite (BITS) at LinuxCon North America.
http://events.linuxfoundation.org/events/linuxcon-north-america/program/slides

Demystifying ACPI and EFI via Python and BITS

Click to access bits-with-demo.pdf

BTW, Josh also gave this talk at LinuxConNA’15 as well:

Everything’s a File Descriptor

Click to access fd_0.pdf

I think I’ve mentioned BITS in this blog before. But just in case I’ve not, BITS is a powerful, strange set of BIOS diagnostic tools. BITS started as a BIOS-centric tool, but now includes some UEFI support as well. BITS uses the GRUB boot manager as it’s UI, using GRUB menus for different features, see the screenshots page for a better understanding:
http://biosbits.org/screenshots/

BITS also includes a Python interpreter, so you can do interactive Python, or write scripts to test firmware. BITS has interfaces for BIOS, UEFI, and ACPI data.
http://biosbits.org/scripting/

Jake Edge wrote an excellent follow-up to Josh’s LinuxCON talk, with an article in LWN.net, discussing BITS’s Python for UEFI and ACPI investigations.

In a talk that could easily be seen as a follow-on to his PyCon 2015 talk, Josh Triplett presented at LinuxCon North America on using Python to explore the low-level firmware of today’s systems. The BIOS Implementation Test Suite (BITS) provides an environment that hearkens back to the days of BASIC, PEEK, and POKE, as he demonstrated at PyCon in Montréal in April, but it is much more than that. In Seattle at LinuxCon, he showed that it can also be used to look at and use the EFI and ACPI code in a system—all from Python.

The article is part of LWN.net subscriber-only content, and has been ‘leaked’ (see next URL below), and as the link on the page mentions, an occasional leak isn’t too bad, and helps with subscriptions. If you don’t have a LWN subscription, please think about it, they are probably the best news source for low-level Linux technologies. They have a 1-month free trial.

After reading this article, Laszlo Ersek of Red Hat started up a thread with Josh on the QEMU and UEFI dev mailing lists, with some new ways of thinking about using BITS Python for ACPI testing. Lots of good ideas on this thread, if you care about QEMU, ACPI, AML, or ACPICA tools please read the thread: sorry, I’m too lazy to summarize all of the ACPI nuances in the thread, it’s only a few messages.

Using Python to investigate EFI and ACPI
Newsgroups: gmane.comp.emulators.qemu, gmane.comp.bios.edk2.devel
http://thread.gmane.org/gmane.comp.emulators.qemu/358997

I hope some of the ACPI/AML testing ideas in this thread happen!

More Information:

https://github.com/biosbits/bits

new tool: Visual UEFI for Windows

~ hucktech ~ 1 Comment

Alex Ionescu just created a new project to help with Visual Studio / EDK-II integration.

https://github.com/ionescu007/VisualUefi

Excerpting from it’s readme, VisualUEFI is 3 things:

1) a Solution and set of Visual Studio 2015 Project Files to allow building the official EDK-II without the use of inf files, Python and 50 other build tools, a custom dependency tracker and build system, and twenty other custom pieces of code. The EDK-II is present as a submodule, directly from the official TianoCore Tree, and no changes are done to it.
2) a Solution and couple of Visual Studio 2015 Project Files to show two UEFI sample components: A UEFI Application, and a UEFI Boot Driver. The code is 100% EDK-II compatible, but built with VisualUEFI instead.
3) a working copy of QEMU64 2.3 for Windows, with a fairly recent UEFI 2.5 OVMF Secure Boot ROM. These will updated on an ongoing basis as needed. This is integrated with the Visual Studio 2015 Sample Solution so that pressing F5 will spin up the instance for testing.

You should be able to open the EDK-II.SLN file and build without any issues in Visual Studio 2015. WDK or other 3rd party installations are not needed. Once the EDK-II libraries are built, you should be able to open the SAMPLES.SLN file and build the two samples, which will create UefiApplication.efi and UefiDriver.efi.

You can press F5 (Run/Debug) from within the Sample Solution, which should spin up the QEMU instance with 512MB of ram, and your release directory as a virtual file system accessible through “fs0:”. You can then try loading the driver with “Load fs0:\UefiDriver.efi”. You can verify its presence by using the Drivers or DevTree commands.

Visual UEFI looks like a nice improvement to Microsoft’s Visual Studio IDE. Thanks, Alex!

(This is the kind of thing I kept expecting the UEFI Forum to release, as an Eclipse plugin, like Yocto and some related projects have done.)

Openstack vulnerability with QCOW2 images

~ hucktech ~ Leave a comment

Today Tristan Cacqueray of Red Hat — and of the OpenStack Vulnerability Management Team — reported a CVE-backed issue with Glance, and it’s use of QCOW2 (“QEMU Copy On Write”, a QEMU-based image format). Glance is the OpenStack Image Service, which provides discovery, registration, and delivery services for disk and server images, as well as a REST-based API.

Glance v2 API host file disclosure through qcow2 backing file
OSSA 2015-014, CVE-2015-5163

“Eric Harney from Red Hat reported a vulnerability in Glance. By importing a qcow2 image with a malicious backing file, an authenticated user may mislead Glance import task action, resulting in the disclosure of any file on the Glance server for which the Glance process user has access to. Only setups using the Glance V2 API are affected by this flaw. This fix will be included in the future 2015.1.2 (kilo) release.”

For the full announcement, including more URLs to patches, see the openstack-announce or oss-security mailing lists. Look to the CVE link in the future, there’s nothing there yet.
http://lists.openstack.org/pipermail/openstack-announce/2015-August/000527.html
https://launchpad.net/bugs/1471912
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-5163
http://docs.openstack.org/developer/glance/
https://wiki.openstack.org/wiki/Glance

(Openstack aside, I wonder if codebases are vulnerable to an “importing a qcow2 image with a malicious backing file” attack?)

OVMF BOF at KVM Forum

~ hucktech ~ Leave a comment

Today on the UEFI development list, Laszlo Ersek of Redhat announced an OVMF BOF at the upcoming KVM Forum, including Paolo Bonzini speaking on adding SMM to OVMF for KVM and Tianocore. This is a massive checkin, and having SMM in OVMF makes it a lot easier to trace and fuzz. Event aside, the list of the last year’s worth of changes to  OVMF/AVMF makes for an interesting read. Heavily-edited announcement follows:

Let’s do an OVMF BoF at this year’s KVM Forum too. Paolo will present “Securing secure boot: system management mode in KVM and Tiano Core” on Thursday, August 20, in the 5:00pm – 5:30pm time slot. Right after that, the BoF section starts at 5:30pm. We should convene and discuss stuff. I don’t have an agenda, so people should bring their ideas and questions (famous last words).

As food for thought, I tried to collect the feature-looking patches from the git history that have been committed since last year’s KVM Forum, and to match them against patch sets on the mailing list:

git log –reverse –oneline –since=2014-10-14 — OvmfPkg/ ArmVirtPkg/ ArmPlatformPkg/ArmVirtualizationPkg/

I attempted to sort them into categories. You can see the list below. The ordering is totally random, it’s just what I ended up with. Corrections / additions welcome. One (missing) feature I’d like to see discussed is: “SataControllerDxe in OVMF”. SMM will require Q35, and the only “IDE” that Q35 speaks is SATA / AHCI. (And you can’t disable that controller on Q35.)

Features completed (… unless marked [pending])

– Xen guest:

  – PV block driver:
    [PATCH v4 00/19] Introducing Xen PV block driver to OVMF

  – Xen for ARM:
    [PATCH v5 00/29] Xen/ARM guest support

– PCI / hw related:

  – PCI on ARM; detect VGA and USB keyboard:
    [PATCH v3 00/28] ArmVirtualizationPkg/ArmVirtualizationQemu: enable PCI
    [PATCH 0/4] ArmVirtualizationPkg: PlatformIntelBdsLib: dynamic console setup

  – support for Q35:
    [PATCH v6 0/9] OVMF: Add support for Qemu Q35 machine type
    [PATCH 1/1] OvmfPkg: QemuBootOrderLib: parse OFW device path nodes of PCI bridges

  – USB3 (ARM and x86):
    [PATCH v2 2/4] ArmVirtualizationPkg/ArmVirtualizationQemu: include XHCI driver
    [PATCH v2 4/4] OvmfPkg: include XHCI driver

  – support TCO watchdog emulation features:
    [PATCH v5 2/2] OvmfPkg/PlatformPei: Initialise RCBA (B0:D31:F0 0xf0) register

  – virtio-vga:
    [PATCH] Add virtio-vga support

  – support extra PCI root buses for NUMA-locality with assigned devices:
    [PATCH v3 00/23] OvmfPkg: support extra PCI root buses

– QEMU config integration:

  – fw_cfg, boot order, and -kernel booting on ARM:
    [PATCH v4 00/13] ArmVirtualizationQemu: support fw_cfg, bootorder, ‘-kernel’
    [PATCH 0/3] ArmVirtPkg: drop support for the ARM BDS

  – support for “-boot menu=on[,splash-time=N]”:
    [PATCH v2 0/3] OVMF, ArmVirt: consume QEMU’s “-boot menu=on[,splash-time=N]”

  – ACPI tables for ARM:
    [PATCH v2 0/3] ACPI over fw_cfg for ARM/AARCH64 qemu guests

  – SMBIOS features: Type 0 default, and SMBIOS 3.0 support on ARM and x86:
    [PATCH] OvmfPkg/SMBIOS: Provide default Type 0 (BIOS Information) structure
    [PATCH v2 0/6] ArmVirtPkg/ArmVirtQemu: support SMBIOS
    [PATCH 0/9] OvmfPkg, ArmVirtPkg: SMBIOS 3.0, round 2

– ARM specific:

  – “fun” with the caches:
    [PATCH v4 0/5] ArmVirtualizationPkg: explicit cache maintenance

  – secure boot:
    [PATCH v3 0/3] ArmVirtualizationQemu: enable support for UEFI Secure Boot

  – performance optimization:
    [PATCH v2 0/6] ArmPkg/ArmVirtPkg: GIC revision detection

  – better handling for the typical Linux terminal (generic driver code, hooked up to ArmVirt):
    [PATCH V4 0/5] Add TtyTerm terminal type

– SMM for OVMF (in progress):
    [PATCH 00/11] Bits and pieces
    [PATCH 00/58] OvmfPkg: support SMM for better security (single VCPU, IA32) [pending]

– Build system:

  – moving to NASM:
    [PATCH 0/7] Convert OVMF assembly to NASM
    [PATCH v2 0/6] OvmfPkg/XenBusDxe: Convert *.asm to NASM.

  – accept UTF-8 in .uni files:
    [PATCH v4 00/10] Support UTF-8 in .uni string files

  – LLVM/clang support for AARCH64 (in progress):
    [PATCH v4 00/13] BaseTools: unify all GCC linker scripts
    [PATCH v4 0/7] small model and clang support for AARCH64 [pending]

– UEFI compliance:

  – support for OsIndications:
    [PATCH v2 0/9] OvmfPkg: PlatformBdsLib cleanups and improvements

  – signal ReadyToBoot:
    [PATCH 1/8] OvmfPkg/PlatformBdsLib: Signal ReadyToBoot before booting QEMU kernel

  – signal EndOfDxe:
    [PATCH v2] ArmVirtPkg: signal EndOxDxe event in PlatformBsdInit
    [PATCH v2 0/6] OvmfPkg: save S3 state at EndOfDxe

  – fix Serial IO Protocol issues flagged by SCT
    [PATCH V4 0/5] Some improvements on serial terminal

– other

  – big OVMF guests:
    [PATCH v2 0/4] OvmfPkg: enable >= 64 GB guests

  – IPv6 (conditionally enabled):
    [PATCH v2] OvmfPkg: enable the IPv6 support

  – many fixes for toolchain warnings and C language misuse

More Information:

https://lists.01.org/mailman/listinfo/edk2-devel
http://events.linuxfoundation.org/events/kvm-forum/program/schedule

Genode OS v15.05

~ hucktech ~ Leave a comment

Found on Joanna’s Twitter feed:

Genode is new to me. Genode Labs makes the “Genode OS Framework”. Genode is a new OS, not a new Linux distribution. It is “a GPLv2-licensed construction kit for building specialized operating systems out of small building blocks including different kernels, device drivers, protocol stacks, and applications”. This current release is a major release for Genode. The new documentation is a large 472 page PDF. The current release adds “rudimentary GPT” support. GPT aside, I don’t see any other UEFI-related technology support, only “BIOS” references to firmware.

“Version 15.05 represents the most substantial release in the history of Genode. It is packed with profound architectural improvements, new device drivers, the extension of the supported base platforms, and a brand new documentation. ”

“We understand the complexity of code and policy as the most fundamental security problem shared by modern general-purpose operating systems. Because of high functional demands and dynamic workloads, however, this complexity cannot be avoided. But it can be organized. Genode is a novel OS architecture that is able to master complexity by applying a strict organizational structure to all software components including device drivers, system services, and applications.”

“The current implementation can be compiled for 8 different kernels: Linux, L4ka::Pistachio, L4/Fiasco, OKL4, NOVA, Fiasco.OC, Codezero, and a custom kernel for running Genode directly on ARM-based hardware. Whereas the Linux version serves us as development vehicle and enables us to rapidly develop the generic parts of the system, the actual target platforms of the framework are microkernels. There is no ‘perfect’ microkernel – and neither should there be one. If a microkernel pretended to be fit for all use cases, it wouldn’t be ‘micro’. Hence, all microkernels differ in terms of their respective features, complexity, and supported hardware architectures.

Genode allows the use of each of the kernels listed above with a rich set of device drivers, protocol stacks, libraries, and applications in a uniform way. For developers, the framework provides an easy way to target multiple different kernels instead of tying the development to a particular kernel technology. For kernel developers, Genode contributes advanced workloads, stress-testing their kernel, and enabling a variety of application use cases that would not be possible otherwise. For users and system integrators, it enables the choice of the kernel that fits best with the requirements at hand for the particular usage scenario.”

Inverse Path’s USB Armoury supports Genode as of 15.02:  “The Genode OS Framework supports the USB armory since version 15.02 implementing a TrustZone Secure virtual-machine monitor (VMM) supervising Linux running in the Normal world. Support is in the very early stages. The Linux kernel requires minimal patching to be executed in the Normal world, at the moment Martin Stein from Genode Labs provides a repository with a patched kernel.”

http://genode.org/documentation/release-notes/15.05
https://github.com/genodelabs/genode
http://sourceforge.net/projects/genode/files/