1. 29 9月, 2012 6 次提交
  2. 24 9月, 2012 5 次提交
    • J
      block: remove keep_read_only flag from BlockDriverState struct · dc1c13d9
      Jeff Cody 提交于
      The keep_read_only flag is no longer used, in favor of the bdrv
      flag BDRV_O_ALLOW_RDWR.
      Signed-off-by: NJeff Cody <jcody@redhat.com>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      dc1c13d9
    • J
      block: convert bdrv_commit() to use bdrv_reopen() · 0bce597d
      Jeff Cody 提交于
      Currently, bdrv_commit() reopens images r/w itself, via risky
      _delete() and _open() calls. Use the new safe method for drive reopen.
      Signed-off-by: NJeff Cody <jcody@redhat.com>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      0bce597d
    • J
      block: Framework for reopening files safely · e971aa12
      Jeff Cody 提交于
      This is based on Supriya Kannery's bdrv_reopen() patch series.
      
      This provides a transactional method to reopen multiple
      images files safely.
      
      Image files are queue for reopen via bdrv_reopen_queue(), and the
      reopen occurs when bdrv_reopen_multiple() is called.  Changes are
      staged in bdrv_reopen_prepare() and in the equivalent driver level
      functions.  If any of the staged images fails a prepare, then all
      of the images left untouched, and the staged changes for each image
      abandoned.
      
      Block drivers are passed a reopen state structure, that contains:
          * BDS to reopen
          * flags for the reopen
          * opaque pointer for any driver-specific data that needs to be
            persistent from _prepare to _commit/_abort
          * reopen queue pointer, if the driver needs to queue additional
            BDS for a reopen
      Signed-off-by: NJeff Cody <jcody@redhat.com>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      e971aa12
    • J
      block: make bdrv_set_enable_write_cache() modify open_flags · 55b110f2
      Jeff Cody 提交于
      bdrv_set_enable_write_cache() sets the bs->enable_write_cache flag,
      but without the flag recorded in bs->open_flags, then next time
      a reopen() is performed the enable_write_cache setting may be
      inadvertently lost.
      
      This will set the flag in open_flags, so it is preserved across
      reopens.
      Signed-off-by: NJeff Cody <jcody@redhat.com>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      55b110f2
    • J
      block: correctly set the keep_read_only flag · be028adc
      Jeff Cody 提交于
      I believe the bs->keep_read_only flag is supposed to reflect
      the initial open state of the device. If the device is initially
      opened R/O, then commit operations, or reopen operations changing
      to R/W, are prohibited.
      
      Currently, the keep_read_only flag is only accurate for the active
      layer, and its backing file. Subsequent images end up always having
      the keep_read_only flag set.
      
      For instance, what happens now:
      
      [  base  ]  kro = 1, ro = 1
          |
          v
      [ snap-1 ]  kro = 1, ro = 1
          |
          v
      [ snap-2 ]  kro = 0, ro = 1
          |
          v
      [ active ]  kro = 0, ro = 0
      
      What we want:
      
      [  base  ]  kro = 0, ro = 1
          |
          v
      [ snap-1 ]  kro = 0, ro = 1
          |
          v
      [ snap-2 ]  kro = 0, ro = 1
          |
          v
      [ active ]  kro = 0, ro = 0
      Signed-off-by: NJeff Cody <jcody@redhat.com>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      be028adc
  3. 12 9月, 2012 2 次提交
  4. 15 8月, 2012 1 次提交
  5. 14 8月, 2012 1 次提交
  6. 03 8月, 2012 2 次提交
  7. 28 7月, 2012 1 次提交
  8. 17 7月, 2012 3 次提交
    • M
      block: Geometry and translation hints are now useless, purge them · 2b584959
      Markus Armbruster 提交于
      There are two producers of these hints: drive_init() on behalf of
      -drive, and hd_geometry_guess().
      
      The only consumer of the hint is hd_geometry_guess().
      
      The callers of hd_geometry_guess() call it only when drive_init()
      didn't set the hints.  Therefore, drive_init()'s hints are never used.
      
      Thus, hd_geometry_guess() only ever sees hints it produced itself in a
      prior call.  Only the first call computes something, subsequent calls
      just repeat the first call's results.  However, hd_geometry_guess() is
      never called more than once: the device models don't, and the block
      device is destroyed on unplug.  Thus, dropping the repeat feature
      doesn't break anything now.
      
      If a block device wasn't destroyed on unplug and could be reused with
      a new device, then repeating old results would be wrong.  Thus,
      dropping the repeat feature prevents future breakage.
      
      This renders the hints unused.  Purge them from the block layer.
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      2b584959
    • M
      hd-geometry: Move disk geometry guessing back from block.c · 9db1c0f7
      Markus Armbruster 提交于
      Commit f3d54fc4 factored it out of hw/ide.c for reuse.  Sensible,
      except it was put into block.c.  Device-specific functionality should
      be kept in device code, not the block layer.  Move it to
      hw/hd-geometry.c, and make stylistic changes required to keep
      checkpatch.pl happy.
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      9db1c0f7
    • M
      fdc: Move floppy geometry guessing back from block.c · 61a8d649
      Markus Armbruster 提交于
      Commit 5bbdbb46 moved it to block.c because "other geometry guessing
      functions already reside in block.c".  Device-specific functionality
      should be kept in device code, not the block layer.  Move it back.
      
      Disk geometry guessing is still in block.c.  To be moved out in a
      later patch series.
      
      Bonus: the floppy type used in pc_cmos_init() now obviously matches
      the one in the FDrive.  Before, we relied on
      bdrv_get_floppy_geometry_hint() picking the same type both in
      fd_revalidate() and in pc_cmos_init().
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      61a8d649
  9. 09 7月, 2012 4 次提交
  10. 15 6月, 2012 8 次提交
  11. 12 6月, 2012 3 次提交
    • M
      change qemu_iovec_to_buf() to match other to,from_buf functions · d5e6b161
      Michael Tokarev 提交于
      It now allows specifying offset within qiov to start from and
      amount of bytes to copy.  Actual implementation is just a call
      to iov_to_buf().
      Signed-off-by: NMichael Tokarev <mjt@tls.msk.ru>
      d5e6b161
    • M
      consolidate qemu_iovec_copy() and qemu_iovec_concat() and make them consistent · 1b093c48
      Michael Tokarev 提交于
      qemu_iovec_concat() is currently a wrapper for
      qemu_iovec_copy(), use the former (with extra
      "0" arg) in a few places where it is used.
      
      Change skip argument of qemu_iovec_copy() from
      uint64_t to size_t, since size of qiov itself
      is size_t, so there's no way to skip larger
      sizes.  Rename it to soffset, to make it clear
      that the offset is applied to src.
      
      Also change the only usage of uint64_t in
      hw/9pfs/virtio-9p.c, in v9fs_init_qiov_from_pdu() -
      all callers of it actually uses size_t too,
      not uint64_t.
      
      One added restriction: as for all other iovec-related
      functions, soffset must point inside src.
      
      Order of argumens is already good:
       qemu_iovec_memset(QEMUIOVector *qiov, size_t offset,
                         int c, size_t bytes)
      vs:
       qemu_iovec_concat(QEMUIOVector *dst,
                         QEMUIOVector *src,
                         size_t soffset, size_t sbytes)
      (note soffset is after _src_ not dst, since it applies to src;
      for memset it applies to qiov).
      
      Note that in many places where this function is used,
      the previous call is qemu_iovec_reset(), which means
      many callers actually want copy (replacing dst content),
      not concat.  So we may want to add a wrapper like
      qemu_iovec_copy() with the same arguments but which
      calls qemu_iovec_reset() before _concat().
      Signed-off-by: NMichael Tokarev <mjt@tls.msk.ru>
      1b093c48
    • M
      allow qemu_iovec_from_buffer() to specify offset from which to start copying · 03396148
      Michael Tokarev 提交于
      Similar to
       qemu_iovec_memset(QEMUIOVector *qiov, size_t offset,
                         int c, size_t bytes);
      the new prototype is:
       qemu_iovec_from_buf(QEMUIOVector *qiov, size_t offset,
                           const void *buf, size_t bytes);
      
      The processing starts at offset bytes within qiov.
      
      This way, we may copy a bounce buffer directly to
      a middle of qiov.
      
      This is exactly the same function as iov_from_buf() from
      iov.c, so use the existing implementation and rename it
      to qemu_iovec_from_buf() to be shorter and to match the
      utility function.
      
      As with utility implementation, we now assert that the
      offset is inside actual iovec.  Nothing changed for
      current callers, because `offset' parameter is new.
      
      While at it, stop using "bounce-qiov" in block/qcow2.c
      and copy decrypted data directly from cluster_data
      instead of recreating a temp qiov for doing that.
      Signed-off-by: NMichael Tokarev <mjt@tls.msk.ru>
      03396148
  12. 30 5月, 2012 2 次提交
    • J
      block: prevent snapshot mode $TMPDIR symlink attack · c2d76497
      Jim Meyering 提交于
      In snapshot mode, bdrv_open creates an empty temporary file without
      checking for mkstemp or close failure, and ignoring the possibility
      of a buffer overrun given a surprisingly long $TMPDIR.
      Change the get_tmp_filename function to return int (not void),
      so that it can inform its two callers of those failures.
      Also avoid the risk of buffer overrun and do not ignore mkstemp
      or close failure.
      Update both callers (in block.c and vvfat.c) to propagate
      temp-file-creation failure to their callers.
      
      get_tmp_filename creates and closes an empty file, while its
      callers later open that presumed-existing file with O_CREAT.
      The problem was that a malicious user could provoke mkstemp failure
      and race to create a symlink with the selected temporary file name,
      thus causing the qemu process (usually root owned) to open through
      the symlink, overwriting an attacker-chosen file.
      
      This addresses CVE-2012-2652.
      http://bugzilla.redhat.com/CVE-2012-2652Signed-off-by: NJim Meyering <meyering@redhat.com>
      Reviewed-by: NStefan Hajnoczi <stefanha@linux.vnet.ibm.com>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      c2d76497
    • J
      block: prevent snapshot mode $TMPDIR symlink attack · eba25057
      Jim Meyering 提交于
      In snapshot mode, bdrv_open creates an empty temporary file without
      checking for mkstemp or close failure, and ignoring the possibility
      of a buffer overrun given a surprisingly long $TMPDIR.
      Change the get_tmp_filename function to return int (not void),
      so that it can inform its two callers of those failures.
      Also avoid the risk of buffer overrun and do not ignore mkstemp
      or close failure.
      Update both callers (in block.c and vvfat.c) to propagate
      temp-file-creation failure to their callers.
      
      get_tmp_filename creates and closes an empty file, while its
      callers later open that presumed-existing file with O_CREAT.
      The problem was that a malicious user could provoke mkstemp failure
      and race to create a symlink with the selected temporary file name,
      thus causing the qemu process (usually root owned) to open through
      the symlink, overwriting an attacker-chosen file.
      
      This addresses CVE-2012-2652.
      http://bugzilla.redhat.com/CVE-2012-2652Reviewed-by: NStefan Hajnoczi <stefanha@linux.vnet.ibm.com>
      Signed-off-by: NJim Meyering <meyering@redhat.com>
      Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
      eba25057
  13. 10 5月, 2012 2 次提交