1. 23 5月, 2016 2 次提交
  2. 19 5月, 2016 3 次提交
  3. 13 5月, 2016 1 次提交
  4. 12 5月, 2016 5 次提交
  5. 02 5月, 2016 5 次提交
    • G
      vga: make sure vga register setup for vbe stays intact (CVE-2016-3712). · fd3c136b
      Gerd Hoffmann 提交于
      Call vbe_update_vgaregs() when the guest touches GFX, SEQ or CRT
      registers, to make sure the vga registers will always have the
      values needed by vbe mode.  This makes sure the sanity checks
      applied by vbe_fixup_regs() are effective.
      
      Without this guests can muck with shift_control, can turn on planar
      vga modes or text mode emulation while VBE is active, making qemu
      take code paths meant for CGA compatibility, but with the very
      large display widths and heigts settable using VBE registers.
      
      Which is good for one or another buffer overflow.  Not that
      critical as they typically read overflows happening somewhere
      in the display code.  So guests can DoS by crashing qemu with a
      segfault, but it is probably not possible to break out of the VM.
      
      Fixes: CVE-2016-3712
      Reported-by: NZuozhi Fzz <zuozhi.fzz@alibaba-inc.com>
      Reported-by: NP J P <ppandit@redhat.com>
      Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
      fd3c136b
    • G
      vga: update vga register setup on vbe changes · 2068192d
      Gerd Hoffmann 提交于
      Call the new vbe_update_vgaregs() function on vbe configuration
      changes, to make sure vga registers are up-to-date.
      Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
      2068192d
    • G
      vga: factor out vga register setup · 7fa5c2c5
      Gerd Hoffmann 提交于
      When enabling vbe mode qemu will setup a bunch of vga registers to make
      sure the vga emulation operates in correct mode for a linear
      framebuffer.  Move that code to a separate function so we can call it
      from other places too.
      Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
      7fa5c2c5
    • G
      vga: add vbe_enabled() helper · bfa0f151
      Gerd Hoffmann 提交于
      Makes code a bit easier to read.
      Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
      bfa0f151
    • G
      vga: fix banked access bounds checking (CVE-2016-3710) · 3bf18170
      Gerd Hoffmann 提交于
      vga allows banked access to video memory using the window at 0xa00000
      and it supports a different access modes with different address
      calculations.
      
      The VBE bochs extentions support banked access too, using the
      VBE_DISPI_INDEX_BANK register.  The code tries to take the different
      address calculations into account and applies different limits to
      VBE_DISPI_INDEX_BANK depending on the current access mode.
      
      Which is probably effective in stopping misprogramming by accident.
      But from a security point of view completely useless as an attacker
      can easily change access modes after setting the bank register.
      
      Drop the bogus check, add range checks to vga_mem_{readb,writeb}
      instead.
      
      Fixes: CVE-2016-3710
      Reported-by: NQinghao Tang <luodalongde@gmail.com>
      Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
      3bf18170
  6. 13 4月, 2016 1 次提交
  7. 11 4月, 2016 2 次提交
    • G
      virtio-gpu: block live migration · fa49e465
      Gerd Hoffmann 提交于
      Feeling a bit nervous putting the full live migration support
      patch (https://patchwork.ozlabs.org/patch/606902/) in that
      late in the 2.6 devel cycle as it carries some non-trivial
      changes.  So disable migration in case virtio-gpu is present
      for now.
      Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
      fa49e465
    • G
      ui/virtio-gpu: add and use qemu_create_displaysurface_pixman · ca58b45f
      Gerd Hoffmann 提交于
      Add a the new qemu_create_displaysurface_pixman function, to create
      a DisplaySurface backed by an existing pixman image.  In that case
      there is no need to create a new pixman image pointing to the same
      backing storage.  We can just use the existing image directly.
      
      This does not only simplify things a bit, but most importantly it
      gets the reference counting right, so the backing storage for the
      pixman image wouldn't be released underneath us.
      
      Use new function in virtio-gpu, where using it actually fixes
      use-after-free crashes.
      
      Cc: qemu-stable@nongnu.org
      Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
      Message-id: 1459499240-742-1-git-send-email-kraxel@redhat.com
      ca58b45f
  8. 23 3月, 2016 3 次提交
    • R
      Replaced get_tick_per_sec() by NANOSECONDS_PER_SECOND · 73bcb24d
      Rutuja Shah 提交于
      This patch replaces get_ticks_per_sec() calls with the macro
      NANOSECONDS_PER_SECOND. Also, as there are no callers, get_ticks_per_sec()
      is then removed.  This replacement improves the readability and
      understandability of code.
      
      For example,
      
          timer_mod(fdctrl->result_timer,
      	      qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) + (get_ticks_per_sec() / 50));
      
      NANOSECONDS_PER_SECOND makes it obvious that qemu_clock_get_ns
      matches the unit of the expression on the right side of the plus.
      Signed-off-by: NRutuja Shah <rutu.shah.26@gmail.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      73bcb24d
    • P
      hw: explicitly include qemu-common.h and cpu.h · 4771d756
      Paolo Bonzini 提交于
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      4771d756
    • M
      include/qemu/osdep.h: Don't include qapi/error.h · da34e65c
      Markus Armbruster 提交于
      Commit 57cb38b3 included qapi/error.h into qemu/osdep.h to get the
      Error typedef.  Since then, we've moved to include qemu/osdep.h
      everywhere.  Its file comment explains: "To avoid getting into
      possible circular include dependencies, this file should not include
      any other QEMU headers, with the exceptions of config-host.h,
      compiler.h, os-posix.h and os-win32.h, all of which are doing a
      similar job to this file and are under similar constraints."
      qapi/error.h doesn't do a similar job, and it doesn't adhere to
      similar constraints: it includes qapi-types.h.  That's in excess of
      100KiB of crap most .c files don't actually need.
      
      Add the typedef to qemu/typedefs.h, and include that instead of
      qapi/error.h.  Include qapi/error.h in .c files that need it and don't
      get it now.  Include qapi-types.h in qom/object.h for uint16List.
      
      Update scripts/clean-includes accordingly.  Update it further to match
      reality: replace config.h by config-target.h, add sysemu/os-posix.h,
      sysemu/os-win32.h.  Update the list of includes in the qemu/osdep.h
      comment quoted above similarly.
      
      This reduces the number of objects depending on qapi/error.h from "all
      of them" to less than a third.  Unfortunately, the number depending on
      qapi-types.h shrinks only a little.  More work is needed for that one.
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      [Fix compilation without the spice devel packages. - Paolo]
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      da34e65c
  9. 17 3月, 2016 1 次提交
  10. 01 3月, 2016 2 次提交
  11. 23 2月, 2016 1 次提交
  12. 10 2月, 2016 1 次提交
  13. 07 2月, 2016 1 次提交
    • P
      virtio: move allocation to virtqueue_pop/vring_pop · 51b19ebe
      Paolo Bonzini 提交于
      The return code of virtqueue_pop/vring_pop is unused except to check for
      errors or 0.  We can thus easily move allocation inside the functions
      and just return a pointer to the VirtQueueElement.
      
      The advantage is that we will be able to allocate only the space that
      is needed for the actual size of the s/g list instead of the full
      VIRTQUEUE_MAX_SIZE items.  Currently VirtQueueElement takes about 48K
      of memory, and this kind of allocation puts a lot of stress on malloc.
      By cutting the size by two or three orders of magnitude, malloc can
      use much more efficient algorithms.
      
      The patch is pretty large, but changes to each device are testable
      more or less independently.  Splitting it would mostly add churn.
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      Reviewed-by: NCornelia Huck <cornelia.huck@de.ibm.com>
      51b19ebe
  14. 03 2月, 2016 4 次提交
  15. 29 1月, 2016 5 次提交
  16. 27 1月, 2016 2 次提交
    • I
      xen: Switch uses of xc_map_foreign_{pages,bulk} to use libxenforeignmemory API. · e0cb42ae
      Ian Campbell 提交于
      In Xen 4.7 we are refactoring parts libxenctrl into a number of
      separate libraries which will provide backward and forward API and ABI
      compatiblity.
      
      One such library will be libxenforeignmemory which provides access to
      privileged foreign mappings and which will provide an interface
      equivalent to xc_map_foreign_{pages,bulk}.
      
      The new xenforeignmemory_map() function behaves like
      xc_map_foreign_pages() when the err argument is NULL and like
      xc_map_foreign_bulk() when err is non-NULL, which maps into the shim
      here onto checking err == NULL and calling the appropriate old
      function.
      
      Note that xenforeignmemory_map() takes the number of pages before the
      arrays themselves, in order to support potentially future use of
      variable-length-arrays in the prototype (in the future, when Xen's
      baseline toolchain requirements are new enough to ensure VLAs are
      supported).
      
      In preparation for adding support for libxenforeignmemory add support
      to the <=4.0 and <=4.6 compat code in xen_common.h to allow us to
      switch to using the new API. These shims will disappear for versions
      of Xen which include libxenforeignmemory.
      
      Since libxenforeignmemory will have its own handle type but for <= 4.6
      the functionality is provided by using a libxenctrl handle we
      introduce a new global xen_fmem alongside the existing xen_xc. In fact
      we make xen_fmem a pointer to the existing xen_xc, which then works
      correctly with both <=4.0 (xc handle is an int) and <=4.6 (xc handle
      is a pointer). In the latter case xen_fmem is actually a double
      indirect pointer, but it all falls out in the wash.
      
      Unlike libxenctrl libxenforeignmemory has an explicit unmap function,
      rather than just specifying that munmap should be used, so the unmap
      paths are updated to use xenforeignmemory_unmap, which is a shim for
      munmap on these versions of xen. The mappings in xen-hvm.c do not
      appear to be unmapped (which makes sense for a qemu-dm process)
      
      In fb_disconnect this results in a change from simply mmap over the
      existing mapping (with an implicit munmap) to expliclty unmapping with
      xenforeignmemory_unmap and then mapping the required anonymous memory
      in the same hole. I don't think this is a problem since any other
      thread which was racily touching this region would already be running
      the risk of hitting the mapping halfway through the call. If this is
      thought to be a problem then we could consider adding an extra API to
      the libxenforeignmemory interface to replace a foreign mapping with
      anonymous shared memory, but I'd prefer not to.
      Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
      Reviewed-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
      Signed-off-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
      e0cb42ae
    • I
      xen: Switch uses of xc_map_foreign_range into xc_map_foreign_pages · 9ed257d1
      Ian Campbell 提交于
      In Xen 4.7 we are refactoring parts libxenctrl into a number of
      separate libraries which will provide backward and forward API and ABI
      compatiblity.
      
      One such library will be libxenforeignmemory which provides access to
      privileged foreign mappings and which will provide an interface
      equivalent to xc_map_foreign_{pages,bulk}.
      
      In preparation for this switch all uses of xc_map_foreign_range to
      xc_map_foreign_pages. This is trivial because size was always
      XC_PAGE_SIZE so the necessary adjustments are trivial:
      
        * Pass &mfn (an array of length 1) instead of mfn. The function
          takes a pointer to const, so there is no possibily of mfn changing
          due to this change.
        * Pass nr_pages=1 instead of size=XC_PAGE_SIZE
      
      There is one wrinkle in xen_console.c:con_initialise() where
      con->ring_ref is an int but can in some code paths (when !xendev->dev)
      be treated as an mfn. I think this is an existing latent truncation
      hazard on platforms where xen_pfn_t is 64-bit and int is 32-bit (e.g.
      amd64, both arm* variants). I'm unsure under what circumstances
      xendev->dev can be NULL or if anything elsewhere ensures the value
      fits into an int. For now I just use a temporary xen_pfn_t to in
      effect upcast the pointer from int* to xen_pfn_t*.
      
      In xenfb.c:common_bind we now explicitly launder the mfn into a
      xen_pfn_t, so it has the correct type to be passed to
      xc_map_foreign_pages and doesn't provoke warnings on 32-bit x86.
      Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
      Reviewed-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
      Signed-off-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
      9ed257d1
  17. 21 1月, 2016 1 次提交