Skip to content

Q
qemu

openeuler / qemu

通知 10
Star 0
Fork 0
Q
qemu

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 26 1月, 2016 1 次提交
  3. 23 12月, 2015 1 次提交
  5. 25 11月, 2015 3 次提交
  7. 04 11月, 2015 1 次提交
    • P
      backends/hostmem-file: Allow to specify full pathname for backing file · 8d31d6b6
      由 Pavel Fedin 提交于 
      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: NPavel Fedin <p.fedin@samsung.com>
Tested-by: NIgor Skalkin <i.skalkin@samsung.com>
Message-Id: <004301d11166$9672fe30$c358fa90$@samsung.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      8d31d6b6
  9. 26 10月, 2015 1 次提交
  11. 25 10月, 2015 1 次提交
  13. 16 9月, 2015 1 次提交
  15. 11 9月, 2015 1 次提交
  17. 02 9月, 2015 1 次提交
  19. 28 8月, 2015 1 次提交
  21. 27 8月, 2015 1 次提交
  23. 24 7月, 2015 1 次提交
  25. 19 3月, 2015 1 次提交
  27. 17 3月, 2015 1 次提交
    • M
      block: Deprecate QCOW/QCOW2 encryption · a1f688f4
      由 Markus Armbruster 提交于 
      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
    OK

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
are!

* 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
on.
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      a1f688f4
  29. 10 3月, 2015 1 次提交
  31. 12 12月, 2014 1 次提交
    • J
      block: vhdx - change .vhdx_create default block state to ZERO · 30af51ce
      由 Jeff Cody 提交于 
      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
VHDX.

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
convert.

[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.
--Stefan]
Signed-off-by: NJeff Cody <jcody@redhat.com>
Reviewed-by: NMax Reitz <mreitz@redhat.com>
Message-id: 85164899eacc86e150c3ceba793cf93b398dedd7.1418018421.git.jcody@redhat.com
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
      30af51ce
  33. 05 11月, 2014 1 次提交
  35. 22 9月, 2014 1 次提交
    • S
      block: delete cow block driver · 550830f9
      由 Stefan Hajnoczi 提交于 
      This patch removes support for the cow file format.

Normally we do not break backwards compatibility but in this case there
is no impact and it is the most logical option.  Extraordinary claims
require extraordinary evidence so I will show why removing the cow block
driver is the right thing to do.

The cow file format is the disk image format for Usermode Linux, a way
of running a Linux system in userspace.  The performance of UML was
never great and it was hacky, but it enjoyed some popularity before
hardware virtualization support became mainstream.

QEMU's block/cow.c is supposed to read this image file format.
Unfortunately the file format was underspecified:

1. Earlier Linux versions used the MAXPATHLEN constant for the backing
   filename field.  The value of MAXPATHLEN can change, so Linux
   switched to a 4096 literal but QEMU has a 1024 literal.

2. Padding was not used on the header struct (both in the Linux kernel
   and in QEMU) so the struct layout varied across architectures.  In
   particular, i386 and x86_64 were different due to int64_t alignment
   differences.  Linux now uses __attribute__((packed)), QEMU does not.

Therefore:

1. QEMU cow images do not conform to the Linux cow image file format.

2. cow images cannot be shared between different host architectures.

This means QEMU cow images are useless and QEMU has not had bug reports
from users actually hitting these issues.

Let's get rid of this thing, it serves no purpose and no one will be
affected.
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
Message-id: 1410877464-20481-1-git-send-email-stefanha@redhat.com
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
      550830f9
  37. 12 9月, 2014 2 次提交
  39. 18 7月, 2014 1 次提交
  41. 07 7月, 2014 1 次提交
  43. 01 7月, 2014 1 次提交
    • C
      qemu-img create: add 'nocow' option · 4ab15590
      由 Chunyan Liu 提交于 
      Add 'nocow' option so that users could have a chance to set NOCOW flag to
newly created files. It's useful on btrfs file system to enhance performance.

Btrfs has low performance when hosting VM images, even more when the guest
in those VM are also using btrfs as file system. One way to mitigate this bad
performance is to turn off COW attributes on VM files. Generally, there are
two ways to turn off NOCOW on btrfs: a) by mounting fs with nodatacow, then
all newly created files will be NOCOW. b) per file. Add the NOCOW file
attribute. It could only be done to empty or new files.

This patch tries the second way, according to the option, it could add NOCOW
per file.

For most block drivers, since the create file step is in raw-posix.c, so we
can do setting NOCOW flag ioctl in raw-posix.c only.

But there are some exceptions, like block/vpc.c and block/vdi.c, they are
creating file by calling qemu_open directly. For them, do the same setting
NOCOW flag ioctl work in them separately.

[Fixed up 082.out due to the new 'nocow' creation option
--Stefan]
Signed-off-by: NChunyan Liu <cyliu@suse.com>
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
      4ab15590
  45. 18 4月, 2014 1 次提交
    • M
      doc: grammify "allows to" · 9d85d557
      由 Michael Tokarev 提交于 
      English language grammar does not allow usage
of the word "allows" directly followed by an
infinitive, declaring constructs like "something
allows to do somestuff" un-grammatical.  Often
it is possible to just insert "one" between "allows"
and "to" to make the construct grammatical, but
usually it is better to re-phrase the statement.

This patch tries to fix 4 examples of "allows to"
usage in qemu doc, but does not address comments
in the code with similar constructs.  It also adds
missing "the" in the same line.
Signed-off-by: NMichael Tokarev <mjt@tls.msk.ru>
      9d85d557
  47. 27 3月, 2014 2 次提交
  49. 01 2月, 2014 1 次提交
    • D
      Describe flaws in qcow/qcow2 encryption in the docs · 136cd19d
      由 Daniel P. Berrange 提交于 
      The qemu-img.texi / qemu-doc.texi files currently describe the
qcow2/qcow2 encryption thus

  "Encryption uses the AES format which is very secure (128 bit
   keys). Use a long password (16 characters) to get maximum
   protection."

While AES is indeed a strong encryption system, the way that
QCow/QCow2 use it results in a poor/weak encryption system.
Due to the use of predictable IVs, based on the sector number
extended to 128 bits, it is vulnerable to chosen plaintext
attacks which can reveal the existence of encrypted data.

The direct use of the user passphrase as the encryption key
also leads to an inability to change the passphrase of an
image. If passphrase is ever compromised the image data will
all be vulnerable, since it cannot be re-encrypted. The admin
has to clone the image files with a new passphrase and then
use a program like shred to secure erase all the old files.

Recommend against any use of QCow/QCow2 encryption, directing
users to dm-crypt / LUKS which can meet modern cryptography
best practices.

[Changed "Qcow" to "qcow" for consistency.
--Stefan]
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
      136cd19d
  51. 22 1月, 2014 1 次提交
  53. 20 12月, 2013 1 次提交
  55. 29 6月, 2013 1 次提交
  57. 26 5月, 2013 1 次提交
    • B
      Remove Sun4c, Sun4d and a few CPUs · 6a4e1771
      由 Blue Swirl 提交于 
      Sun4c and Sun4d architectures and related CPUs are not fully implemented
(especially Sun4c MMU) and there has been no interest for them.

Likewise, a few CPUs (Cypress, Ross etc) are only half implemented.

Remove the machines and CPUs, they can be re-added if needed later.
Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>
      6a4e1771
  59. 12 5月, 2013 1 次提交
  61. 26 4月, 2013 1 次提交
  63. 15 4月, 2013 2 次提交
  65. 04 3月, 2013 2 次提交
  67. 27 2月, 2013 1 次提交
    • P
      qemu-log: default to stderr for logging output · 989b697d
      由 Peter Maydell 提交于 
      Switch the default for qemu_log logging output from "/tmp/qemu.log"
to stderr. This is an incompatible change in some sense, but logging
is mostly used for debugging purposes so it shouldn't affect production
use. The previous behaviour can be obtained by adding "-D /tmp/qemu.log"
to the command line.

This change requires us to:
 * update all the documentation/help text (we take the opportunity
   to smooth out minor inconsistencies between the phrasing in
   linux-user/bsd-user/system help messages)
 * make linux-user and bsd-user defer to qemu-log for the default
   logging destination rather than overriding it themselves
 * ensure that all logfile closing is done via qemu_log_close()
   and that that function doesn't close stderr
as well as the obvious change to the behaviour of do_qemu_set_log()
when no logfile name has been specified.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
Message-id: 1361901160-28729-1-git-send-email-peter.maydell@linaro.org
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
      989b697d