Commit efb4f3b6 authored by Peter Maydell's avatar Peter Maydell
Browse files

Merge remote-tracking branch 'remotes/stefanha/tags/block-pull-request' into staging 



Pull request

# gpg: Signature made Fri 10 May 2019 14:02:22 BST
# gpg:                using RSA key 8695A8BFD3F97CDAAC35775A9CA4ABB381AB73C8
# gpg: Good signature from "Stefan Hajnoczi <stefanha@redhat.com>" [full]
# gpg:                 aka "Stefan Hajnoczi <stefanha@gmail.com>" [full]
# Primary key fingerprint: 8695 A8BF D3F9 7CDA AC35  775A 9CA4 ABB3 81AB 73C8

* remotes/stefanha/tags/block-pull-request:
  docs: add Security chapter to the documentation
  docs: add Secure Coding Practices to developer docs
  aio-posix: ensure poll mode is left when aio_notify is called
  block/io.c: fix for the allocation failure
  block: Add coroutine_fn to bdrv_check_co_entry
  util/readline: Add braces to fix checkpatch errors
  util: readline: replace tab indent by four spaces to fix checkpatch errors
  util/readline: add a space to fix errors by checkpatch tool

Signed-off-by: default avatarPeter Maydell <peter.maydell@linaro.org>
parents 5f022626 e8412576

Makefile

+1 −1
Original line number Diff line number Diff line
@@ -976,7 +976,7 @@ qemu-doc.html qemu-doc.info qemu-doc.pdf qemu-doc.txt: \ 
	qemu-img.texi qemu-nbd.texi qemu-options.texi qemu-option-trace.texi \

	qemu-deprecated.texi qemu-monitor.texi qemu-img-cmds.texi qemu-ga.texi \

	qemu-monitor-info.texi docs/qemu-block-drivers.texi \

	docs/qemu-cpu-models.texi

	docs/qemu-cpu-models.texi docs/security.texi



docs/interop/qemu-ga-ref.dvi docs/interop/qemu-ga-ref.html \

    docs/interop/qemu-ga-ref.info docs/interop/qemu-ga-ref.pdf \

block.c

+1 −1
Original line number Diff line number Diff line
@@ -4121,7 +4121,7 @@ typedef struct CheckCo { 
    int ret;

} CheckCo;



static void bdrv_check_co_entry(void *opaque)

static void coroutine_fn bdrv_check_co_entry(void *opaque)

{

    CheckCo *cco = opaque;

    cco->ret = bdrv_co_check(cco->bs, cco->res, cco->fix);

block/io.c

+1 −1
Original line number Diff line number Diff line
@@ -1516,7 +1516,7 @@ static int coroutine_fn bdrv_co_do_pwrite_zeroes(BlockDriverState *bs, 
            assert(!bs->supported_zero_flags);

        }



        if (ret == -ENOTSUP && !(flags & BDRV_REQ_NO_FALLBACK)) {

        if (ret < 0 && !(flags & BDRV_REQ_NO_FALLBACK)) {

            /* Fall back to bounce buffer if write zeroes is unsupported */

            BdrvRequestFlags write_flags = flags & ~BDRV_REQ_ZERO_WRITE;

docs/devel/index.rst

+1 −0
Original line number Diff line number Diff line
@@ -20,3 +20,4 @@ Contents: 
   stable-process

   testing

   decodetree

   secure-coding-practices

docs/devel/secure-coding-practices.rst

0 → 100644
+106 −0
Original line number Diff line number Diff line 
=======================

Secure Coding Practices

=======================

This document covers topics that both developers and security researchers must

be aware of so that they can develop safe code and audit existing code

properly.



Reporting Security Bugs

-----------------------

For details on how to report security bugs or ask questions about potential

security bugs, see the `Security Process wiki page

<https://wiki.qemu.org/SecurityProcess>`_.



General Secure C Coding Practices

---------------------------------

Most CVEs (security bugs) reported against QEMU are not specific to

virtualization or emulation.  They are simply C programming bugs.  Therefore

it's critical to be aware of common classes of security bugs.



There is a wide selection of resources available covering secure C coding.  For

example, the `CERT C Coding Standard

<https://wiki.sei.cmu.edu/confluence/display/c/SEI+CERT+C+Coding+Standard>`_

covers the most important classes of security bugs.



Instead of describing them in detail here, only the names of the most important

classes of security bugs are mentioned:



* Buffer overflows

* Use-after-free and double-free

* Integer overflows

* Format string vulnerabilities



Some of these classes of bugs can be detected by analyzers.  Static analysis is

performed regularly by Coverity and the most obvious of these bugs are even

reported by compilers.  Dynamic analysis is possible with valgrind, tsan, and

asan.



Input Validation

----------------

Inputs from the guest or external sources (e.g. network, files) cannot be

trusted and may be invalid.  Inputs must be checked before using them in a way

that could crash the program, expose host memory to the guest, or otherwise be

exploitable by an attacker.



The most sensitive attack surface is device emulation.  All hardware register

accesses and data read from guest memory must be validated.  A typical example

is a device that contains multiple units that are selectable by the guest via

an index register::



  typedef struct {

      ProcessingUnit unit[2];

      ...

  } MyDeviceState;



  static void mydev_writel(void *opaque, uint32_t addr, uint32_t val)

  {

      MyDeviceState *mydev = opaque;

      ProcessingUnit *unit;



      switch (addr) {

      case MYDEV_SELECT_UNIT:

          unit = &mydev->unit[val];   <-- this input wasn't validated!

          ...

      }

  }



If ``val`` is not in range [0, 1] then an out-of-bounds memory access will take

place when ``unit`` is dereferenced.  The code must check that ``val`` is 0 or

1 and handle the case where it is invalid.



Unexpected Device Accesses

--------------------------

The guest may access device registers in unusual orders or at unexpected

moments.  Device emulation code must not assume that the guest follows the

typical "theory of operation" presented in driver writer manuals.  The guest

may make nonsense accesses to device registers such as starting operations

before the device has been fully initialized.



A related issue is that device emulation code must be prepared for unexpected

device register accesses while asynchronous operations are in progress.  A

well-behaved guest might wait for a completion interrupt before accessing

certain device registers.  Device emulation code must handle the case where the

guest overwrites registers or submits further requests before an ongoing

request completes.  Unexpected accesses must not cause memory corruption or

leaks in QEMU.



Invalid device register accesses can be reported with

``qemu_log_mask(LOG_GUEST_ERROR, ...)``.  The ``-d guest_errors`` command-line

option enables these log messages.



Live Migration

--------------

Device state can be saved to disk image files and shared with other users.

Live migration code must validate inputs when loading device state so an

attacker cannot gain control by crafting invalid device states.  Device state

is therefore considered untrusted even though it is typically generated by QEMU

itself.



Guest Memory Access Races

-------------------------

Guests with multiple vCPUs may modify guest RAM while device emulation code is

running.  Device emulation code must copy in descriptors and other guest RAM

structures and only process the local copy.  This prevents

time-of-check-to-time-of-use (TOCTOU) race conditions that could cause QEMU to

crash when a vCPU thread modifies guest RAM while device emulation is

processing it.