1. 15 Jun, 2017 1 commit
  2. 04 Jun, 2017 2 commits
  3. 12 May, 2017 1 commit
  4. 10 May, 2017 1 commit
  5. 09 May, 2017 1 commit
    • Daniel P. Berrange's avatar
      Default to GSSAPI (Kerberos) instead of DIGEST-MD5 for SASL · c6a9a9f5
      Daniel P. Berrange authored
      RFC 6331 documents a number of serious security weaknesses in
      the SASL DIGEST-MD5 mechanism. As such, QEMU should not be
      using or recommending it as a default mechanism for VNC auth
      with SASL.
      GSSAPI (Kerberos) is the only other viable SASL mechanism that
      can provide secure session encryption so enable that by defalt
      as the replacement. If users have TLS enabled for VNC, they can
      optionally decide to use SCRAM-SHA-1 instead of GSSAPI, allowing
      plain username and password auth.
      Reviewed-by: 's avatarEric Blake <eblake@redhat.com>
      Signed-off-by: 's avatarDaniel P. Berrange <berrange@redhat.com>
  6. 24 Jan, 2017 2 commits
  7. 18 Jan, 2017 1 commit
  8. 05 Dec, 2016 1 commit
  9. 07 Oct, 2016 4 commits
  10. 12 May, 2016 1 commit
  11. 21 Mar, 2016 3 commits
    • Markus Armbruster's avatar
      ivshmem: Require master to have ID zero · 62a830b6
      Markus Armbruster authored
      Migration with ivshmem needs to be carefully orchestrated to work.
      Exactly one peer (the "master") migrates to the destination, all other
      peers need to unplug (and disconnect), migrate, plug back (and
      reconnect).  This is sort of documented in qemu-doc.
      If peers connect on the destination before migration completes, the
      shared memory can get messed up.  This isn't documented anywhere.  Fix
      that in qemu-doc.
      To avoid messing up register IVPosition on migration, the server must
      assign the same ID on source and destination.  ivshmem-spec.txt leaves
      ID assignment unspecified, however.
      Amend ivshmem-spec.txt to require the first client to receive ID zero.
      The example ivshmem-server complies: it always assigns the first
      unused ID.
      For a bit of additional safety, enforce ID zero for the master.  This
      does nothing when we're not using a server, because the ID is zero for
      all peers then.
      Signed-off-by: 's avatarMarkus Armbruster <armbru@redhat.com>
      Reviewed-by: 's avatarMarc-André Lureau <marcandre.lureau@redhat.com>
      Message-Id: <1458066895-20632-40-git-send-email-armbru@redhat.com>
    • Markus Armbruster's avatar
      ivshmem: Split ivshmem-plain, ivshmem-doorbell off ivshmem · 5400c02b
      Markus Armbruster authored
      ivshmem can be configured with and without interrupt capability
      (a.k.a. "doorbell").  The two configurations have largely disjoint
      options, which makes for a confusing (and badly checked) user
      interface.  Moreover, the device can't tell the guest whether its
      doorbell is enabled.
      Create two new device models ivshmem-plain and ivshmem-doorbell, and
      deprecate the old one.
      Changes from ivshmem:
      * PCI revision is 1 instead of 0.  The new revision is fully backwards
        compatible for guests.  Guests may elect to require at least
        revision 1 to make sure they're not exposed to the funny "no shared
        memory, yet" state.
      * Property "role" replaced by "master".  role=master becomes
        master=on, role=peer becomes master=off.  Default is off instead of
      * Property "use64" is gone.  The new devices always have 64 bit BARs.
      Changes from ivshmem to ivshmem-plain:
      * The Interrupt Pin register in PCI config space is zero (does not use
        an interrupt pin) instead of one (uses INTA).
      * Property "x-memdev" is renamed to "memdev".
      * Properties "shm" and "size" are gone.  Use property "memdev"
      * Property "msi" is gone.  The new device can't have MSI-X capability.
        It can't interrupt anyway.
      * Properties "ioeventfd" and "vectors" are gone.  They're meaningless
        without interrupts anyway.
      Changes from ivshmem to ivshmem-doorbell:
      * Property "msi" is gone.  The new device always has MSI-X capability.
      * Property "ioeventfd" defaults to on instead of off.
      * Property "size" is gone.  The new device can only map all the shared
        memory received from the server.
      Guests can easily find out whether the device is configured for
      interrupts by checking for MSI-X capability.
      Note: some code added in sub-optimal places to make the diff easier to
      review.  The next commit will move it to more sensible places.
      Signed-off-by: 's avatarMarkus Armbruster <armbru@redhat.com>
      Reviewed-by: 's avatarMarc-André Lureau <marcandre.lureau@redhat.com>
      Message-Id: <1458066895-20632-37-git-send-email-armbru@redhat.com>
    • Markus Armbruster's avatar
      ivshmem: Propagate errors through ivshmem_recv_setup() · 1309cf44
      Markus Armbruster authored
      This kills off the funny state described in the previous commit.
      Simplify ivshmem_io_read() accordingly, and update documentation.
      Signed-off-by: 's avatarMarkus Armbruster <armbru@redhat.com>
      Message-Id: <1458066895-20632-27-git-send-email-armbru@redhat.com>
      Reviewed-by: 's avatarMarc-André Lureau <marcandre.lureau@redhat.com>
  12. 18 Mar, 2016 1 commit
  13. 19 Feb, 2016 1 commit
  14. 11 Feb, 2016 1 commit
  15. 04 Feb, 2016 1 commit
  16. 26 Jan, 2016 1 commit
  17. 22 Dec, 2015 1 commit
  18. 25 Nov, 2015 3 commits
  19. 04 Nov, 2015 1 commit
    • Pavel Fedin's avatar
      backends/hostmem-file: Allow to specify full pathname for backing file · 8d31d6b6
      Pavel Fedin authored
      This allows to explicitly specify file name to use with the backend. This
      is important when using it together with ivshmem in order to make it backed
      by hugetlbfs. By default filename is autogenerated using mkstemp(), and the
      file is unlink()ed after creation, effectively making it anonymous. This is
      not very useful with ivshmem because it ends up in a memory which cannot be
      accessed by something else.
      Distinction between directory and file name is done by stat() check. If an
      existing directory is given, the code keeps old behavior. Otherwise it
      creates or opens a file with the given pathname.
      Signed-off-by: 's avatarPavel Fedin <p.fedin@samsung.com>
      Tested-by: 's avatarIgor Skalkin <i.skalkin@samsung.com>
      Message-Id: <004301d11166$9672fe30$c358fa90$@samsung.com>
      Signed-off-by: 's avatarPaolo Bonzini <pbonzini@redhat.com>
  20. 26 Oct, 2015 1 commit
  21. 24 Oct, 2015 1 commit
  22. 16 Sep, 2015 1 commit
  23. 11 Sep, 2015 1 commit
  24. 01 Sep, 2015 1 commit
  25. 28 Aug, 2015 1 commit
  26. 27 Aug, 2015 1 commit
  27. 24 Jul, 2015 1 commit
  28. 19 Mar, 2015 1 commit
  29. 16 Mar, 2015 1 commit
    • Markus Armbruster's avatar
      block: Deprecate QCOW/QCOW2 encryption · a1f688f4
      Markus Armbruster authored
      We've steered users away from QCOW/QCOW2 encryption for a while,
      because it's a flawed design (commit 136cd19d Describe flaws in
      qcow/qcow2 encryption in the docs).
      In addition to flawed crypto, we have comically bad usability, and
      plain old bugs.  Let me show you.
      = Example images =
      I'm going to use a raw image as backing file, and two QCOW2 images,
      one encrypted, and one not:
          $ qemu-img create -f raw backing.img 4m
          Formatting 'backing.img', fmt=raw size=4194304
          $ qemu-img create -f qcow2 -o encryption,backing_file=backing.img,backing_fmt=raw geheim.qcow2 4m
          Formatting 'geheim.qcow2', fmt=qcow2 size=4194304 backing_file='backing.img' backing_fmt='raw' encryption=on cluster_size=65536 lazy_refcounts=off
          $ qemu-img create -f qcow2 -o backing_file=backing.img,backing_fmt=raw normal.qcow2 4m
          Formatting 'normal.qcow2', fmt=qcow2 size=4194304 backing_file='backing.img' backing_fmt='raw' encryption=off cluster_size=65536 lazy_refcounts=off
      = Usability issues =
      == Confusing startup ==
      When no image is encrypted, and you don't give -S, QEMU starts the
      guest immediately:
          $ qemu-system-x86_64 -nodefaults -display none -monitor stdio normal.qcow2
          QEMU 2.2.50 monitor - type 'help' for more information
          (qemu) info status
          VM status: running
      But as soon as there's an encrypted image in play, the guest is *not*
      started, with no notification whatsoever:
          $ qemu-system-x86_64 -nodefaults -display none -monitor stdio geheim.qcow2
          QEMU 2.2.50 monitor - type 'help' for more information
          (qemu) info status
          VM status: paused (prelaunch)
      If the user figured out that he needs to type "cont" to enter his
      keys, the confusion enters the next level: "cont" asks for at most
      *one* key.  If more are needed, it then silently does nothing.  The
      user has to type "cont" once per encrypted image:
          $ qemu-system-x86_64 -nodefaults -display none -monitor stdio -drive if=none,file=geheim.qcow2 -drive if=none,file=geheim.qcow2
          QEMU 2.2.50 monitor - type 'help' for more information
          (qemu) info status
          VM status: paused (prelaunch)
          (qemu) c
          none0 (geheim.qcow2) is encrypted.
          Password: ******
          (qemu) info status
          VM status: paused (prelaunch)
          (qemu) c
          none1 (geheim.qcow2) is encrypted.
          Password: ******
          (qemu) info status
          VM status: running
      == Incorrect passwords not caught ==
      All existing encryption schemes give you the GIGO treatment: garbage
      password in, garbage data out.  Guests usually refuse to mount
      garbage, but other usage is prone to data loss.
      == Need to stop the guest to add an encrypted image ==
          $ qemu-system-x86_64 -nodefaults -display none -monitor stdio
          QEMU 2.2.50 monitor - type 'help' for more information
          (qemu) info status
          VM status: running
          (qemu) drive_add "" if=none,file=geheim.qcow2
          Guest must be stopped for opening of encrypted image
          (qemu) stop
          (qemu) drive_add "" if=none,file=geheim.qcow2
      Commit c3adb58f added this restriction.  Before, we could expose images
      lacking an encryption key to guests, with potentially catastrophic
      results.  See also "Use without key is not always caught".
      = Bugs =
      == Use without key is not always caught ==
      Encrypted images can be in an intermediate state "opened, but no key".
      The weird startup behavior and the need to stop the guest are there to
      ensure the guest isn't exposed to that state.  But other things still
      * drive_backup
          $ qemu-system-x86_64 -nodefaults -display none -monitor stdio geheim.qcow2
          QEMU 2.2.50 monitor - type 'help' for more information
          (qemu) drive_backup -f ide0-hd0 out.img raw
          Formatting 'out.img', fmt=raw size=4194304
        I guess this writes encrypted data to raw image out.img.  Good luck
        with figuring out how to decrypt that again.
      * commit
          $ qemu-system-x86_64 -nodefaults -display none -monitor stdio geheim.qcow2
          QEMU 2.2.50 monitor - type 'help' for more information
          (qemu) commit ide0-hd0
        I guess this writes encrypted data into the unencrypted raw backing
        image, effectively destroying it.
      == QMP device_add of usb-storage fails when it shouldn't ==
      When the image is encrypted, device_add creates the device, defers
      actually attaching it to when the key becomes available, then fails.
      This is wrong.  device_add must either create the device and succeed,
      or do nothing and fail.
          $ qemu-system-x86_64 -nodefaults -display none -usb -qmp stdio -drive if=none,id=foo,file=geheim.qcow2
          {"QMP": {"version": {"qemu": {"micro": 50, "minor": 2, "major": 2}, "package": ""}, "capabilities": []}}
          { "execute": "qmp_capabilities" }
          {"return": {}}
          { "execute": "device_add", "arguments": { "driver": "usb-storage", "id": "bar", "drive": "foo" } }
          {"error": {"class": "DeviceEncrypted", "desc": "'foo' (geheim.qcow2) is encrypted"}}
          {"execute":"device_del","arguments": { "id": "bar" } }
          {"timestamp": {"seconds": 1426003440, "microseconds": 237181}, "event": "DEVICE_DELETED", "data": {"path": "/machine/peripheral/bar/bar.0/legacy[0]"}}
          {"timestamp": {"seconds": 1426003440, "microseconds": 238231}, "event": "DEVICE_DELETED", "data": {"device": "bar", "path": "/machine/peripheral/bar"}}
          {"return": {}}
      This stuff is worse than useless, it's a trap for users.
      If people become sufficiently interested in encrypted images to
      contribute a cryptographically sane implementation for QCOW2 (or
      whatever other format), then rewriting the necessary support around it
      from scratch will likely be easier and yield better results than
      fixing up the existing mess.
      Let's deprecate the mess now, drop it after a grace period, and move
      Signed-off-by: 's avatarMarkus Armbruster <armbru@redhat.com>
      Reviewed-by: 's avatarEric Blake <eblake@redhat.com>
      Signed-off-by: 's avatarKevin Wolf <kwolf@redhat.com>
  30. 10 Mar, 2015 1 commit
  31. 12 Dec, 2014 1 commit
    • Jeff Cody's avatar
      block: vhdx - change .vhdx_create default block state to ZERO · 30af51ce
      Jeff Cody authored
      The VHDX spec specifies that the default new block state is
      PAYLOAD_BLOCK_NOT_PRESENT for a dynamic VHDX image, and
      PAYLOAD_BLOCK_FULLY_PRESENT for a fixed VHDX image.
      However, in order to create space-efficient VHDX images with qemu-img
      convert, it is desirable to be able to set has_zero_init to true for
      There is currently an option when creating VHDX images, to use block
      state ZERO for new blocks.  However, this currently defaults to 'off'.
      In order to be able to eventually set has_zero_init to true for VHDX,
      this needs to default to 'on'.
      This patch changes the default to 'on', and provides some help
      information to warn against setting it to 'off' when using qemu-img
      [Max Reitz pointed out that a full stop was missing at the end of the
      VHDX_BLOCK_OPT_ZERO option help text.  I have added it.
      Signed-off-by: 's avatarJeff Cody <jcody@redhat.com>
      Reviewed-by: 's avatarMax Reitz <mreitz@redhat.com>
      Message-id: 85164899eacc86e150c3ceba793cf93b398dedd7.1418018421.git.jcody@redhat.com
      Signed-off-by: 's avatarStefan Hajnoczi <stefanha@redhat.com>