You are looking at the HTML representation of the XML format.
HTML is good for debugging, but is unsuitable for application use.
Specify the format parameter to change the output format.
To see the non HTML representation of the XML format, set format=xml.
See the complete documentation, or
API help for more information.
<allpages gapcontinue="Testing/CCWTestDevice" />
<page pageid="951" ns="0" title="SecurityProcess">
<rev contentformat="text/x-wiki" contentmodel="wikitext" xml:space="preserve">QEMU takes security very seriously, and we aim to take immediate action to address serious security-related problems that involve our product.
Please report any suspected security vulnerability in QEMU to the following addresses.
You can use GPG keys for respective receipients to communicate with us securely.
If you do, please upload your GPG public key or supply it to us in some other way, so
that we can communicate to you in a secure way, too!
Please include the tag [QEMU-SECURITY] on the subject line to help us identify your message
|+ QEMU Security Contact List: please copy everyone on this list.
|Contact Person(s) || Contact Address || Company || GPG key || GPG key fingerprint
|Michael S. Tsirkin || firstname.lastname@example.org || Red Hat Inc. || [[https://email@example.com GPG key ]] || Fingerprint=0270 606B 6F3C DF3D 0B17 0970 C350 3912 AFBE 8E67
|Petr Matousek || firstname.lastname@example.org || Red Hat Inc. || [[https://pgp.mit.edu/pks/lookup?op=vindex&search=0x3E786F42C44977CA GPG key ]] || Fingerprint=8107 AF16 A416 F9AF 18F3 D874 3E78 6F42 C449 77CA
|Stefano Stabellini || email@example.com || Independent || [[https://firstname.lastname@example.org GPG key ]] || Fingerprint=D04E 33AB A51F 67BA 07D3 0AEA 894F 8F48 70E1 AE90
| Security Response Team || email@example.com || Red Hat Inc. || [[https://access.redhat.com/site/security/team/contact/#contact GPG key]]
|Michael Roth || firstname.lastname@example.org || IBM || [[https://email@example.com GPG key ]] || Fingerprint=CEAC C9E1 5534 EBAB B82D 3FA0 3353 C9CE F108 B584
|Prasad J Pandit || firstname.lastname@example.org || Red Hat Inc. || [[https://pgp.mit.edu/pks/lookup?op=vindex&search=0xDD133D32FE5B041F GPG key]] || Fingerprint=47AF CE69 3A90 54AA 9045 1053 DD13 3D32 FE5B 041F
=== How to Contact Us Securely ===
We use a GNU Privacy Guard (GnuPG or GPG) keys to secure communications. Mail sent to members of the list can be encrypted with public keys of all members of the list. We expect to change some of the keys we use from time to time. Should we change the key, the previous keys will be revoked.
=== How we respond ===
Maintainers listed on the security reporting list operate a
policy of responsible disclosure. As such they agree that any
information you share with them about security issues that are not
public knowledge is kept confidential within respective affiliated companies.
It is not passed on to any third-party, including Xen Security Project, without your
Email sent to us is read and acknowledged with a non-automated response. For issues that are complicated and require significant attention, we will open an investigation and keep you informed of our progress. We might take one or more of the following steps:
==== Publication embargo ====
As a security issue reported, that is not already publically disclosed elsewhere, has an embargo date assigned and communicated to reporter. Embargo periods will be negotiated by mutual agreement between members of the security team and other relevant parties to the problem. Members of the security contact list agree not to publically disclose any details of the security issue until the embargo date expires.
==== CVE allocation ====
An security issue is assigned with a CVE number. The CVE numbers will usually be allocated by one of the vendor security engineers on the security contact list.
=== When to Contact the QEMU Security Contact List ===
You should contact the Security Contact List if:
* You think there may be a security vulnerability in QEMU.
* You are unsure about how a known vulnerability affects QEMU.
* You can contact us in English. We are unable to respond in other languages.
=== When '''not''' to Contact the QEMU Security Contact List ===
* You need assistance in a language other than English.
* You require technical assistance (for example, "how do I configure QEMU?").
* You need help upgrading QEMU due to security alerts.
* Your issue is not security related.
=== How impact and severity of a bug is decided ===
All security issues in QEMU are not equal. Based on the parts of the QEMU sources wherein the bug is found, its impact and severity could vary.
In fact, at times, what appears to be a genuine security flaw, might not be considered so because it lies in the generally trusted sources and/or configurations. Ie. It can only be exercised in use cases where QEMU and everything interacting with it is trusted.
For example, recently a genuine case of out of bounds (OOB) memory access (ie. buffer overflow) issue was found and fixed in the SD Host Controller emulation(hw/sd/sdhci.c).
Upstream commit [http://git.qemu.org/?p=qemu.git;a=commit;h=9201bb9 9201bb9 "sdhci.c: Limit the maximum block size"]
Prima facie, this bug appears to be a genuine security flaw, with potentially severe implications. But digging further down, it shows that there are only two ways to use SD Host Controller emulation, one is via 'sdhci-pci' interface and the other is via 'generic-sdhci' interface.
Of these two, the 'sdhci-pci' interface is relatively new and has been disabled by default in the upstream QEMU releases, so guests could not possibly use it for any purpose.
Upstream commit [http://git.qemu.org/?p=qemu.git;a=commit;h=1910913 1910913 "sdhci: Make device "sdhci-pci" unavailable with -device"]
The 'generic-sdhci' interface has only one user in 'Xilinx Zynq Baseboard emulation' (ie. hw/arm/xilinx_zynq.c). Xilinx Zynq is a programmable systems on chip (SoC) device.
While upstream QEMU does emulate this device, in practice it is used to facilitate cross-platform developmental efforts. I.e. using QEMU emulation to write programs for the SoC device. In such developer environments, it is assumed that the guest is generally trusted.
And thus, this seemingly genuine buffer overflow issue turned out to be a security non-issue.
General considerations: for triaging QEMU issues to be security OR non-security
* Is QEMU used in conjunction with a hypervisor...?
* Is QEMU used to run virtualised production environments...?
* Is QEMU used to offer virtualised production services? OR is it used as development platform...?
* Is there any feasible way for a malicious party to exploit this flaw and cause real damage...?
* Is the flaw found in the gdbstub server source...?
* Does QEMU configuration/setup has any untrusted users...?
=== What to Send to the QEMU Security Contact List ===
Please provide as much information about your system and the issue as possible when contacting the list.</rev>
<page pageid="375" ns="0" title="Testing">
<rev contentformat="text/x-wiki" contentmodel="wikitext" xml:space="preserve">== Tests included in the QEMU source ==
QEMU includes a test suite comprising:
* [[Testing/UnitTests|unit tests]] for library code
* [[Features/QTest|QTest]]-based tests, which inject predefined stimuli into the device emulation code.
* [[Testing/QemuIoTests|qemu-iotests]], a regression test suite for the block layer code.
=== <tt>make check</tt> ===
The unit tests and QTest-based can be run with "<tt>make check</tt>". Use "<tt>make check-help</tt>" to see a list of other available test targets and parameters (for example, you can use "<tt>make check SPEED=slow V=1</tt>" for a verbose, more thorough test run). These unit tests are used in [[#Continuous Integration|our continuous integration]] systems, based on [[Testing/Travis|Travis]] and [[Testing/Patchew|Patchew]].
=== qemu-iotests ===
<blockquote>''Main article: [[Testing/QemuIoTests]]''</blockquote>
qemu-iotests is run from the toplevel build directory with <tt>make check-block</tt>. A full version of the testsuite, taking around half an hour to run, is run with <tt>sh ../tests/check-block.sh</tt>.
=== <tt>make docker</tt> ===
The build system supports a number of Docker build targets which allow the source tree to be built and tested on a number of different Linux distributions regardless of your host. See [[Testing/DockerBuild]] for more information.
=== device-crash-test script ===
The <tt>scripts/device-crash-test</tt> script can be used to run QEMU with multiple
<tt>-machine</tt> and <tt>-device</tt> combinations, to look for obvious crashes machine or
== System emulation ==
We have [[Testing/System Images|a collection of links to disk images]] which can be used to test system emulation.
== User mode emulation ==
Here are some links to executables that can be used to test Linux user mode emulation:
* [https://kos.to/linux-user-busyboxes-0.1.tar.xz linux-user-busyboxes-0.1.tar.xz] - Collection of static busybox binaries for almost all Linux target architectures that QEMU simulates. For quick smoke testing of Linux user mode emulation.
It is also possible to [[Testing/LTP|run the Linux Test Project's syscall test suite under the Linux user mode emulation]].
== Dynamic code analysis ==
This includes any test to detect memory leaks, reads of uninitialised memory,
buffer overflows or other forms of illegal memory access, that needs QEMU to be run, not merely compiled.
=== Valgrind ===
Typically these kind of tests are done using [[Documentation/Debugging with Valgrind|Valgrind]] on a Linux host.
Any of the disk images and executables listed above can be used in such tests.
# Simple i386 boot test (BIOS only) with Valgrind.
valgrind --leak-check=full --track-origins=yes --verbose qemu-system-i386
=== clang UBSan ===
The [[https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html clang undefined behavior sanitizer]] can be used to warn about accidental uses of C undefined behavior when QEMU is run. To use it you first need to configure and build QEMU with a clang compiler with the right options:
(cd build/clang && ../../configure --cc=clang --cxx=clang++ \
'--extra-cflags=-fsanitize=undefined -fno-sanitize=shift-base -Wno-address-of-packed-member -Werror')
make -C build/clang -j8
(The -fno-sanitize=shift-base is a workaround for [[https://bugs.llvm.org/show_bug.cgi?id=25552 LLVM bug 25552]] where it did not correctly suppress some shift-related warnings when -fwrapv was in use. If you're using a clang where that bug is fixed, likely 3.9 or better, you can drop it.)
Then when you run the resulting QEMU binaries messages will be printed when UB is invoked:
hw/core/loader.c:67:15: runtime error: null pointer passed as argument 1, which is declared to never be null
See the clang documentation for more information including how to produce stack backtraces on errors.
== Static code analysis ==
There are a number of tools which analyse C code and try to detect typical
errors. None of these tools is perfect, so using different tools with QEMU
will detect more bugs. Be prepared to also get lots of false warnings!
=== ccc-analyzer (clang) ===
This is an example used on Debian. It needs package clang.
# Start from the root directory with QEMU code.
mkdir -f bin/debug/ccc-analyzer
../../../configure --enable-debug --enable-trace-backend=stderr \
At least on my Linux host (1 GiB RAM, 2 GiB swap), make hangs when
ccc-analyzer analyzes target-mips/translate.c: function decode_opc
is too complex for the analyzer and takes all memory. Killing the
clang process helps in this situation. It's needed 6 times because
there are 4 MIPS system emulations and 2 Linux MIPS user emulations.
I guess this is because target-mips/translate.c contains switches with
cases covering a very large range; assuming ccc-analyzer expands these
case ranges somehow, it probably blows up memory completely.
=== smatch ===
Here is a typical example using smatch (from git://repo.or.cz/smatch.git):
# Start from the root directory with QEMU code.
mkdir -f bin/debug/smatch
CHECK="smatch" ../../../configure --enable-debug --cc=cgcc --host-cc=cgcc
This example expects that smatch and cgcc are installed in your PATH
(if not, you must add absolute paths to the example).
=== Coverity ===
Periodic scans of QEMU are done on the public Coverity Scan service (scan.coverity.com). You can request access on their website, and the administrator will grant it if you are an active participant in QEMU development.
Coverity is confused slightly by multiple definitions of functions with the same name. For this reason, Coverity scans are done as follows:
./configure --audio-drv-list=oss,alsa,sdl,pa --disable-werror
cov-build --dir cov-int make
tar cvf - cov-int | xz > cov-int.tar.xz
Notice that libqemustub.a is ignored by Coverity. This is because some stubs call <tt>abort()</tt> and this causes dead-code false positives. The file cov-int.tar.xz can then be uploaded to [https://scan.coverity.com/projects/378/builds/new Coverity Scan's "Submit build" page]. Customarily, the "project version" is set to the output of <tt>git describe HEAD</tt> and the "description/tag" is set to "commit XYZ" where XYZ is the '''full''' SHA1 hash of the commit.
== Avocado and Avocado-VT ==
Avocado is a generic testing framework, while Avocado-VT adds support for Virtualization testing, including first level support for testing QEMU.
To get started with Avocado-VT please visit:
To learn more about Avocado please visit:
After installing it, you can use Avocado-VT tests with your own build of QEMU:
avocado run boot --vt-qemu-bin /path/to/qemu-system-x86_64
== Continuous Integration ==
There is no central point of Continuous Integration for the QEMU project. Instead various individuals and companies have set-up various automated systems that attempt to build and test QEMU to various degrees.
== See Also ==
* [https://github.com/ehabkost/gdb-qemu gdb-qemu], a set of scripts that look for compatibility bugs by poking at QEMU internal data structures using GDB
The following sub-pages exist: