Tag: qemu

How to Debug the Linux Kernel with QEMU and Libvirt

~ hucktech ~ Leave a comment

[…In this article, we explain how you can debug your Linux kernel and its modules during runtime. This article will be useful for Linux kernel developers who want to speed up the time to market of their software.[…]

https://www.apriorit.com/dev-blog/597-debug-linux-kernel-qemu-libvirt

OpenBSD/arm64 on QEMU with networking

~ hucktech ~ Leave a comment

With the increasing popularity of ARM64/AArch64 systems, from the Raspberry Pi 3 and PINE64 to Fujitsu’s move away from SPARC64 supercomputers, there hasn’t been a better time to get started with learning this architecture. I wanted to make a start to an Aarch64 assembly language tutorial but didn’t have access to my RPi3, so I looked into the state of QEMU’s emulation. I didn’t need RPi3-specific hardware – which is just as well as I can’t remember off-hand how the bootcode and start.elf crap would work with QEMU – anyway, I opted for a generic device using Linaro’s EDK2 UEFI firmware. The first pre-built EDK2 binary I downloaded wouldn’t play nicely with the OpenBSD kernel so I grabbed a release mentioned by the FreeBSD team – which worked.[…]

https://cryogenix.net/OpenBSD_arm64_qemu.html

 

Two articles on QEMU and virtualization

~ hucktech ~ Leave a comment

https://developer.ibm.com/articles/enhancing-qemu-virtio-scsi-with-block-limits-vpd-emulation/

https://binarydebt.wordpress.com/2018/10/14/intel-virtualisation-how-vt-x-kvm-and-qemu-work-together/amp/

arm_now: QEMU-based tool to setup VMs for security research

~ hucktech ~ Leave a comment

arm_now is a qemu powered tool that allows instant setup of virtual machines on arm cpu, mips, powerpc, nios2, x86 and more, for reverse, exploit, fuzzing and programming purpose.

https://github.com/nongiach/arm_now

Alt Text

 

LAVA: Large-scale Automated Vulnerability Addition for PANDA

~ hucktech ~ Leave a comment

Re: https://firmwaresecurity.com/2015/11/23/panda-vm/ and https://firmwaresecurity.com/2016/12/01/panda-2-0-released/

PANDA is an open-source Platform for Architecture-Neutral Dynamic Analysis. It is built upon the QEMU whole system emulator, and so analyses have access to all code executing in the guest and all data. PANDA adds the ability to record and replay executions, enabling iterative, deep, whole system analyses. Further, the replay log files are compact and shareable, allowing for repeatable experiments. A nine billion instruction boot of FreeBSD, e.g., is represented by only a few hundred MB. PANDA leverages QEMU’s support of thirteen different CPU architectures to make analyses of those diverse instruction sets possible within the LLVM IR. In this way, PANDA can have a single dynamic taint analysis, for example, that precisely supports many CPUs. PANDA analyses are written in a simple plugin architecture which includes a mechanism to share functionality between plugins, increasing analysis code re-use and simplifying complex analysis development.

LAVA (Large Scale Automated Vulnerability Addition) for PANDA:

Evaluating and improving bug-finding tools is currently difficult due to a shortage of ground truth corpora (i.e., software that has known bugs with triggering inputs). LAVA attempts to solve this problem by automatically injecting bugs into software. Every LAVA bug is accompanied by an input that triggers it whereas normal inputs are extremely unlikely to do so. These vulnerabilities are synthetic but, we argue, still realistic, in the sense that they are embedded deep within programs and are triggered by real inputs. Our work forms the basis of an approach for generating large ground-truth vulnerability corpora on demand, enabling rigorous tool evaluation and providing a high-quality target for tool developers. 

https://github.com/panda-re/lava

https://github.com/panda-re/panda

PANDA’s LAVA is separate from the Linaro LAVA project, which the Tags on this blog points to.

 

 

QEMU v2.12.0 released (with Spectre/Meltdown update)

~ hucktech ~ Leave a comment

QEMU version 2.12.0 released
24 Apr 2018
This release contains 2700+ commits from 204 authors.

* Spectre/Meltdown mitigation support for x86/pseries/s390 guests.
* Better IPMI support for Platform Events and SEL logging in internal BMC emulation
* SMBIOS support for “OEM Strings”, which can be used for automating guest image activation without relying on network-based querying

[…]A previous post detailed how QEMU/KVM might be affected by Spectre/Meltdown attacks, and what the plan was to mitigate them in QEMU 2.11.1 (and eventually QEMU 2.12). QEMU 2.11.1 is now available, and contains the aforementioned mitigation functionality for x86 guests, along with additional mitigation functionality for pseries and s390x guests (ARM guests do not currently require additional QEMU patches). However, enabling this functionality requires additional configuration beyond just updating QEMU, which we want to address with this post.[…]

https://www.qemu.org/2018/04/24/qemu-2-12-0/

More on QEMU and Spectre/Meltdown:

https://www.qemu.org/2018/02/14/qemu-2-11-1-and-spectre-update/

https://www.qemu.org/2018/01/04/spectre/

QEMU has RISC-V support

~ hucktech ~ Leave a comment

part 2:https://www.sifive.com/blog/2018/04/25/risc-v-qemu-part-2-the-risc-v-qemu-port-is-up stream/

part 1: https://www.sifive.com/blog/2017/12/20/risc-v-qemu-part-1-privileged-isa-hifive1-virtio/

see-also Sifive’s statement on Spectre/Meltdown:

https://www.sifive.com/blog/2018/01/05/sifive-statement-on-meltdown-and-spectre/

Emulating Exynos 4210 BootROM in QEMU

~ hucktech ~ Leave a comment

[…]This project allows to debug BootROM dynamically with GDB. It has been helpful for analyzing secure boot mechanism that loads and authenticates the next stage from flash memory.[…]

Nicely-written. Includes coverage of U-Boot and U-Boot Secure Boot.

https://www.fredericb.info/2018/03/emulating-exynos-4210-bootrom-in-qemu.html#emulating-exynos-4210-bootrom-in-qemu
https://github.com/frederic/qemu-exynos-bootrom

Exynos 4 Dual 45nm

PS: I just learned about this blog. Catching up, there are some interesting older posts, eg:

Amlogic S905 SoC: bypassing the (not so) Secure Boot to dump the BootROM
https://www.fredericb.info/2016/10/amlogic-s905-soc-bypassing-not-so.html#amlogic-s905-soc-bypassing-not-so

docker-edk2-uefi: Docker container for Tianocore EDK2 dev

~ hucktech ~ Leave a comment

Container to build Tianocore EDK2 MdeModules and OVMF and run in OVMF with qemu using X over ssh

UEFI EDKII Development Environment

This docker container can be used to build projects based on the Tiano EDKII UEFI project. It is possible to selected the branch of the EDKII project to be used and compiled at container creation as well as the target architecture. Build Tools are compiled on first ssh login triggered in bashrc. qemu can be run with X over ssh. Scripts are included to build MdeModulePkg and OVMF. Script included to create base for OVMF qemu environment and start qemu (script only for x86/64 right now).[…]

https://hub.docker.com/r/geneerik/docker-edk2-uefi/

Somewhat related, I also found these UEFI/Docker options:

https://hub.docker.com/r/rojuinex/edk2-uefi/~/dockerfile/
https://hub.docker.com/r/michas2/edk2-test/~/dockerfile/

PS: Wondering what he’s been messing with UEFI on:

 

Firmware exploitation with PNF Software’s JEB

~ hucktech ~ Leave a comment

PNF Software has a series of blog posts on how to use their JEB product to reverse firmware:

Firmware Exploitation with JEB:

In this series of blog posts I will show how JEB’s MIPS decompiler 1 can help you find and exploit software vulnerabilities in embedded devices. To do so, we will use Praetorian’s Damn Vulnerable Router Firmware (DVRF) written by b1ack0wl. DVRF is a custom firmware made to run on a Linksys E1550 router containing a bunch of memory corruption vulnerabilities. The goal of the DVRF is to serve as a playground to learn exploitation on the MIPS architecture. As far as I know, there are no write-ups of the challenges on the Internet. For the readers interested in testing the challenges by themselves, I suggest to follow the DVRF tutorial, and getting a complete MIPSEL Debian QEMU image as it allows the usual exploit development workflow on Linux, without any limits on the available tools.[…]

https://www.pnfsoftware.com/blog/firmware-exploitation-with-jeb-part-1/
https://www.pnfsoftware.com/blog/firmware-exploitation-with-jeb-part-2/
https://www.pnfsoftware.com/blog/firmware-exploitation-with-jeb-part-3-reversing-the-smartrgs-sr505n/

https://www.pnfsoftware.com/jeb2/mips

PyREBox

~ hucktech ~ Leave a comment

PyREBox is a Python scriptable Reverse Engineering sandbox. It is based on QEMU, and its goal is to aid reverse engineering by providing dynamic analysis and debugging capabilities from a different perspective. PyREBox allows to inspect a running QEMU VM, modify its memory or registers, and to instrument its execution, by creating simple scripts in python to automate any kind of analysis. QEMU (when working as a whole-system-emulator) emulates a complete system (CPU, memory, devices…). By using VMI techniques, it does not require to perform any modification into the guest operating system, as it transparently retrieves information from its memory at run-time. Several academic projects such as DECAF, PANDA, S2E, or AVATAR, have previously leveraged QEMU based instrumentation to overcome reverse engineering tasks. These projects allow to write plugins in C/C++, and implement several advanced features such as dynamic taint analysis, symbolic execution, or even record and replay of execution traces. With PyREBox, we aim to apply this technology focusing on keeping the design simple, and on the usability of the system for threat analysts.

https://github.com/Cisco-Talos/pyrebox

Alex updates smmtestbuildscript for Fedora 26 and QEMU 2.9

~ hucktech ~ Leave a comment

A while ago[1], Alex Floyd of PreOS Security wrote a shell script to help codify this wiki article[2] by Laslo Ersek of Red Hat, setting up a UEFI SMM/OVMF testing environment for Fedora-based systems. Recently, Alex updated this script to work with the recently-released Fedora 26. Quoting email from Alex on the changes in this release:

The build script has been updated for Fedora 26 support. It now uses the native QEMU 2.9 library from Fedora 26 and no longer builds a snapshot of QEMU 2.9 which makes some new testing possibilities available.

https://github.com/gencymex/smmtestbuildscript

[1] https://firmwaresecurity.com/2017/04/19/shell-script-for-laszlos-smm-test-environment-article/

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

 

UEFI/SMM stability and performance improvements in QEMU 2.9 and edk2/OVMF git 296153c5, included with Fedora 26

~ hucktech ~ Leave a comment

Fedora 26 just released, and it ships with QEMU v2.9 and an updated OVMF, which adds SMM security improvements. Quoting email from Laszlo Ersek of Red Hat:

QEMU 2.9 is part of Fedora 26. The full changelog for QEMU 2.9 is here:

http://wiki.qemu.org/ChangeLog/2.9

The broadcast SMI feature is just one tiny line in the huge list (and it only mentions the generic negotiation feature, not the specific broadcast one):

“The q35 machine type offers SMI feature negotiation to interested guest firmware.”

QEMU v2.9 is important for running the SMM driver stack of edk2 — more precisely, machine type “pc-q35-2.9” is important — because it offers negotiable SMI broadcast, i.e., where one VCPU writes to ioport 0xB2, and the SMI is raised synchronously on all VCPUs. See:

https://bugzilla.redhat.com/show_bug.cgi?id=1412313 [ovmf]
https://bugzilla.redhat.com/show_bug.cgi?id=1412327 [qemu]

QEMU v2.10 — more precisely, machine type “pc-q35-2.10” — will bring another SMM-related improvement, although not as critical as SMI broadcast. (And I guess it will be available in Fedora 27.) We call it “extended TSEG”, and it allows the QEMU user to specify more than 8MB SMRAM on the cmdline. This is important if you have a huge number of VCPUs, or huge guest RAM (into the TB range) because those things have a linearly growing SMRAM footprint (albeit with small constant factors). See:

https://bugzilla.redhat.com/show_bug.cgi?id=1447027 [qemu and ovmf, both committed]
https://bugzilla.redhat.com/show_bug.cgi?id=1469338 [libvirt, under design]

The patches (qemu and ovmf) committed for BZ#1447027 above solve the “many VCPUs” question. The “huge guest RAM” question needs more platform code in OVMF; the patch for that is on edk2-devel, pending review:

https://bugzilla.redhat.com/show_bug.cgi?id=1468526 [ovmf, pending review]

More info:
https://getfedora.org/
https://en.wikipedia.org/wiki/System_Management_Mode

VM escape – QEMU case study on Phrack

~ hucktech ~ Leave a comment

http://www.phrack.org/papers/vm-escape-qemu-case-study.html

I wish more people wrote articles for Phrack.