1. 20 Jun, 2016 1 commit
  2. 13 Jun, 2016 2 commits
  3. 07 Jun, 2016 1 commit
  4. 19 May, 2016 1 commit
  5. 30 Mar, 2016 1 commit
  6. 22 Mar, 2016 2 commits
    • Markus Armbruster's avatar
      include/crypto: Include qapi-types.h or qemu/bswap.h instead of qemu-common.h · 7136fc1d
      Markus Armbruster authored
      qemu-common.h should only be included by .c files.  Its file comment
      explains why: "No header file should depend on qemu-common.h, as this
      would easily lead to circular header dependencies."
      Several include/crypto/ headers include qemu-common.h, but either need
      just qapi-types.h from it, or qemu/bswap.h, or nothing at all.  Replace or
      drop the include accordingly.  tests/test-crypto-secret.c now misses
      qemu/module.h, so include it there.
      Signed-off-by: 's avatarMarkus Armbruster <armbru@redhat.com>
      Signed-off-by: 's avatarPaolo Bonzini <pbonzini@redhat.com>
    • Markus Armbruster's avatar
      include/qemu/osdep.h: Don't include qapi/error.h · da34e65c
      Markus Armbruster authored
      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: 's avatarMarkus Armbruster <armbru@redhat.com>
      [Fix compilation without the spice devel packages. - Paolo]
      Signed-off-by: 's avatarPaolo Bonzini <pbonzini@redhat.com>
  7. 21 Mar, 2016 2 commits
  8. 17 Mar, 2016 12 commits
  9. 02 Feb, 2016 1 commit
  10. 01 Feb, 2016 1 commit
  11. 29 Jan, 2016 1 commit
  12. 22 Jan, 2016 1 commit
  13. 23 Dec, 2015 5 commits
  14. 18 Dec, 2015 2 commits
    • Daniel P. Berrange's avatar
      crypto: add support for loading encrypted x509 keys · 1d7b5b4a
      Daniel P. Berrange authored
      Make use of the QCryptoSecret object to support loading of
      encrypted x509 keys. The optional 'passwordid' parameter
      to the tls-creds-x509 object type, provides the ID of a
      secret object instance that holds the decryption password
      for the PEM file.
       # printf "123456" > mypasswd.txt
       # $QEMU \
          -object secret,id=sec0,filename=mypasswd.txt \
          -object tls-creds-x509,passwordid=sec0,id=creds0,\
                  dir=/home/berrange/.pki/qemu,endpoint=server \
          -vnc :1,tls-creds=creds0
      This requires QEMU to be linked to GNUTLS >= 3.1.11. If
      GNUTLS is too old an error will be reported if an attempt
      is made to pass a decryption password.
      Reviewed-by: 's avatarEric Blake <eblake@redhat.com>
      Signed-off-by: 's avatarDaniel P. Berrange <berrange@redhat.com>
    • Daniel P. Berrange's avatar
      crypto: add QCryptoSecret object class for password/key handling · ac1d8878
      Daniel P. Berrange authored
      Introduce a new QCryptoSecret object class which will be used
      for providing passwords and keys to other objects which need
      sensitive credentials.
      The new object can provide secret values directly as properties,
      or indirectly via a file. The latter includes support for file
      descriptor passing syntax on UNIX platforms. Ordinarily passing
      secret values directly as properties is insecure, since they
      are visible in process listings, or in log files showing the
      CLI args / QMP commands. It is possible to use AES-256-CBC to
      encrypt the secret values though, in which case all that is
      visible is the ciphertext.  For ad hoc developer testing though,
      it is fine to provide the secrets directly without encryption
      so this is not explicitly forbidden.
      The anticipated scenario is that libvirtd will create a random
      master key per QEMU instance (eg /var/run/libvirt/qemu/$VMNAME.key)
      and will use that key to encrypt all passwords it provides to
      QEMU via '-object secret,....'.  This avoids the need for libvirt
      (or other mgmt apps) to worry about file descriptor passing.
      It also makes life easier for people who are scripting the
      management of QEMU, for whom FD passing is significantly more
      Providing data inline (insecure, only for ad hoc dev testing)
        $QEMU -object secret,id=sec0,data=letmein
      Providing data indirectly in raw format
        printf "letmein" > mypasswd.txt
        $QEMU -object secret,id=sec0,file=mypasswd.txt
      Providing data indirectly in base64 format
        $QEMU -object secret,id=sec0,file=mykey.b64,format=base64
      Providing data with encryption
        $QEMU -object secret,id=master0,file=mykey.b64,format=base64 \
              -object secret,id=sec0,data=[base64 ciphertext],\
      	           keyid=master0,iv=[base64 IV],format=base64
      Note that 'format' here refers to the format of the ciphertext
      data. The decrypted data must always be in raw byte format.
      More examples are shown in the updated docs.
      Reviewed-by: 's avatarEric Blake <eblake@redhat.com>
      Signed-off-by: 's avatarDaniel P. Berrange <berrange@redhat.com>
  15. 04 Dec, 2015 1 commit
    • Daniel P. Berrange's avatar
      crypto: avoid two coverity false positive error reports · 0e1d0245
      Daniel P. Berrange authored
      In qcrypto_tls_creds_get_path() coverity complains that
      we are checking '*creds' for NULL, despite having
      dereferenced it previously. This is harmless bug due
      to fact that the trace call was too early. Moving it
      after the cleanup gets the desired semantics.
      In qcrypto_tls_creds_check_cert_key_purpose() coverity
      complains that we're passing a pointer to a previously
      free'd buffer into gnutls_x509_crt_get_key_purpose_oid()
      This is harmless because we're passing a size == 0, so
      gnutls won't access the buffer, but rather just report
      what size it needs to be. We can avoid it though by
      explicitly setting the buffer to NULL after free'ing
      Signed-off-by: 's avatarDaniel P. Berrange <berrange@redhat.com>
      Reviewed-by: 's avatarEric Blake <eblake@redhat.com>
      Signed-off-by: 's avatarMichael Tokarev <mjt@tls.msk.ru>
  16. 18 Nov, 2015 3 commits
  17. 22 Oct, 2015 3 commits
    • Daniel P. Berrange's avatar
      crypto: add sanity checking of plaintext/ciphertext length · 3a661f1e
      Daniel P. Berrange authored
      When encrypting/decrypting data, the plaintext/ciphertext
      buffers are required to be a multiple of the cipher block
      size. If this is not done, nettle will abort and gcrypt
      will report an error. To get consistent behaviour add
      explicit checks upfront for the buffer sizes.
      Signed-off-by: 's avatarDaniel P. Berrange <berrange@redhat.com>
    • Daniel P. Berrange's avatar
      crypto: don't let builtin aes crash if no IV is provided · eb2a770b
      Daniel P. Berrange authored
      If no IV is provided, then use a default IV of all-zeros
      instead of crashing. This gives parity with gcrypt and
      nettle backends.
      Signed-off-by: 's avatarDaniel P. Berrange <berrange@redhat.com>
    • Daniel P. Berrange's avatar
      crypto: allow use of nettle/gcrypt to be selected explicitly · 91bfcdb0
      Daniel P. Berrange authored
      Currently the choice of whether to use nettle or gcrypt is
      made based on what gnutls is linked to. There are times
      when it is desirable to be able to force build against a
      specific library. For example, if testing changes to QEMU's
      crypto code all 3 possible backends need to be checked
      regardless of what the local gnutls uses.
      It is also desirable to be able to enable nettle/gcrypt
      for cipher/hash algorithms, without enabling gnutls
      for TLS support.
      This gives two new configure flags, which allow the
      following possibilities
      Automatically determine nettle vs gcrypt from what
      gnutls links to (recommended to minimize number of
      crypto libraries linked to)
      Automatically determine nettle vs gcrypt based on
      which is installed
       ./configure --disable-gnutls
      Force use of nettle
       ./configure --enable-nettle
      Force use of gcrypt
       ./configure --enable-gcrypt
      Force use of built-in AES & crippled-DES
       ./configure --disable-nettle --disable-gcrypt
      Signed-off-by: 's avatarDaniel P. Berrange <berrange@redhat.com>