1. 12 9月, 2016 3 次提交
  2. 12 8月, 2016 1 次提交
  3. 26 7月, 2016 1 次提交
  4. 21 7月, 2016 3 次提交
  5. 12 7月, 2016 3 次提交
  6. 04 7月, 2016 5 次提交
    • D
      crypto: allow default TLS priority to be chosen at build time · a1c5e949
      Daniel P. Berrange 提交于
      Modern gnutls can use a global config file to control the
      crypto priority settings for TLS connections. For example
      the priority string "@SYSTEM" instructs gnutls to find the
      priority setting named "SYSTEM" in the global config file.
      
      Latest gnutls GIT codebase gained the ability to reference
      multiple priority strings in the config file, with the first
      one that is found to existing winning. This means it is now
      possible to configure QEMU out of the box with a default
      priority of "@QEMU,SYSTEM", which says to look for the
      settings "QEMU" first, and if not found, use the "SYSTEM"
      settings.
      
      To make use of this facility, we introduce the ability to
      set the QEMU default priority at build time via a new
      configure argument.  It is anticipated that distro vendors
      will set this when building QEMU to a suitable value for
      use with distro crypto policy setup. eg current Fedora
      would run
      
       ./configure --tls-priority=@SYSTEM
      
      while future Fedora would run
      
       ./configure --tls-priority=@QEMU,SYSTEM
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      a1c5e949
    • D
      crypto: add support for TLS priority string override · 13f12430
      Daniel P. Berrange 提交于
      The gnutls default priority is either "NORMAL" (most historical
      versions of gnutls) which is a built-in label in gnutls code,
      or "@SYSTEM" (latest gnutls on Fedora at least) which refers
      to an admin customizable entry in a gnutls config file.
      
      Regardless of which default is used by a distro, they are both
      global defaults applying to all applications using gnutls. If
      a single application on the system needs to use a weaker set
      of crypto priorities, this potentially forces the weakness onto
      all applications. Or conversely if a single application wants a
      strong default than all others, it can't do this via the global
      config file.
      
      This adds an extra parameter to the tls credential object which
      allows the mgmt app / user to explicitly provide a priority
      string to QEMU when configuring TLS.
      
      For example, to use the "NORMAL" priority, but disable SSL 3.0
      one can now configure QEMU thus:
      
        $QEMU -object tls-creds-x509,id=tls0,dir=/home/berrange/qemutls,\
                      priority="NORMAL:-VERS-SSL3.0" \
              ..other args...
      
      If creating tls-creds-anon, whatever priority the user specifies
      will always have "+ANON-DH" appended to it, since that's mandatory
      to make the anonymous credentials work.
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      13f12430
    • D
      crypto: implement sha224, sha384, sha512 and ripemd160 hashes · 9164b897
      Daniel P. Berrange 提交于
      Wire up the nettle and gcrypt hash backends so that they can
      support the sha224, sha384, sha512 and ripemd160 hash algorithms.
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      9164b897
    • D
      crypto: switch hash code to use nettle/gcrypt directly · 0c16c056
      Daniel P. Berrange 提交于
      Currently the internal hash code is using the gnutls hash APIs.
      GNUTLS in turn is wrapping either nettle or gcrypt. Not only
      were the GNUTLS hash APIs not added until GNUTLS 2.9.10, but
      they don't expose support for all the algorithms QEMU needs
      to use with LUKS.
      
      Address this by directly wrapping nettle/gcrypt in QEMU and
      avoiding GNUTLS's extra layer of indirection. This gives us
      support for hash functions on a much wider range of platforms
      and opens up ability to support more hash functions. It also
      avoids a GNUTLS bug which would not correctly handle hashing
      of large data blocks if int != size_t.
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      0c16c056
    • D
      crypto: fix handling of iv generator hash defaults · 8b7cdba3
      Daniel P. Berrange 提交于
      When opening an existing LUKS volume, if the iv generator is
      essiv, then the iv hash algorithm is mandatory to provide. We
      must report an error if it is omitted in the cipher mode spec,
      not silently default to hash 0 (md5).  If the iv generator is
      not essiv, then we explicitly ignore any iv hash algorithm,
      rather than report an error, for compatibility with dm-crypt.
      
      When creating a new LUKS volume, if the iv generator is essiv
      and no iv hsah algorithm is provided, we should default to
      using the sha256 hash.
      Reported-by: NPaolo Bonzini <pbonzini@redhat.com>
      Reviewed-by: NEric Blake <eblake@redhat.com>
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      8b7cdba3
  7. 21 6月, 2016 1 次提交
  8. 13 6月, 2016 2 次提交
  9. 07 6月, 2016 1 次提交
  10. 19 5月, 2016 1 次提交
  11. 30 3月, 2016 1 次提交
  12. 23 3月, 2016 2 次提交
    • M
      include/crypto: Include qapi-types.h or qemu/bswap.h instead of qemu-common.h · 7136fc1d
      Markus Armbruster 提交于
      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: NMarkus Armbruster <armbru@redhat.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      7136fc1d
    • 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
  13. 21 3月, 2016 2 次提交
  14. 18 3月, 2016 1 次提交
  15. 17 3月, 2016 11 次提交
  16. 02 2月, 2016 1 次提交
  17. 01 2月, 2016 1 次提交