Skip to content
Snippets Groups Projects
  1. Jun 29, 2021
  2. May 15, 2020
    • Markus Armbruster's avatar
      qom: Drop parameter @errp of object_property_add() & friends · d2623129
      Markus Armbruster authored
      
      The only way object_property_add() can fail is when a property with
      the same name already exists.  Since our property names are all
      hardcoded, failure is a programming error, and the appropriate way to
      handle it is passing &error_abort.
      
      Same for its variants, except for object_property_add_child(), which
      additionally fails when the child already has a parent.  Parentage is
      also under program control, so this is a programming error, too.
      
      We have a bit over 500 callers.  Almost half of them pass
      &error_abort, slightly fewer ignore errors, one test case handles
      errors, and the remaining few callers pass them to their own callers.
      
      The previous few commits demonstrated once again that ignoring
      programming errors is a bad idea.
      
      Of the few ones that pass on errors, several violate the Error API.
      The Error ** argument must be NULL, &error_abort, &error_fatal, or a
      pointer to a variable containing NULL.  Passing an argument of the
      latter kind twice without clearing it in between is wrong: if the
      first call sets an error, it no longer points to NULL for the second
      call.  ich9_pm_add_properties(), sparc32_ledma_realize(),
      sparc32_dma_realize(), xilinx_axidma_realize(), xilinx_enet_realize()
      are wrong that way.
      
      When the one appropriate choice of argument is &error_abort, letting
      users pick the argument is a bad idea.
      
      Drop parameter @errp and assert the preconditions instead.
      
      There's one exception to "duplicate property name is a programming
      error": the way object_property_add() implements the magic (and
      undocumented) "automatic arrayification".  Don't drop @errp there.
      Instead, rename object_property_add() to object_property_try_add(),
      and add the obvious wrapper object_property_add().
      
      Signed-off-by: default avatarMarkus Armbruster <armbru@redhat.com>
      Reviewed-by: default avatarEric Blake <eblake@redhat.com>
      Reviewed-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Message-Id: <20200505152926.18877-15-armbru@redhat.com>
      [Two semantic rebase conflicts resolved]
      d2623129
  3. Jul 19, 2019
  4. Jun 12, 2019
  5. Jun 01, 2018
  6. Sep 04, 2017
  7. Jul 04, 2016
    • Daniel P. Berrangé's avatar
      crypto: add support for TLS priority string override · 13f12430
      Daniel P. Berrangé authored
      
      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: default avatarDaniel P. Berrange <berrange@redhat.com>
      13f12430
  8. Mar 22, 2016
    • 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: default avatarMarkus Armbruster <armbru@redhat.com>
      [Fix compilation without the spice devel packages. - Paolo]
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      da34e65c
  9. Feb 01, 2016
  10. Jan 29, 2016
  11. Dec 04, 2015
    • Daniel P. Berrangé's avatar
      crypto: avoid two coverity false positive error reports · 0e1d0245
      Daniel P. Berrangé 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
      it.
      
      Signed-off-by: default avatarDaniel P. Berrange <berrange@redhat.com>
      Reviewed-by: default avatarEric Blake <eblake@redhat.com>
      Signed-off-by: default avatarMichael Tokarev <mjt@tls.msk.ru>
      0e1d0245
  12. Sep 15, 2015
    • Daniel P. Berrangé's avatar
      crypto: introduce new base module for TLS credentials · a090187d
      Daniel P. Berrangé authored
      
      Introduce a QCryptoTLSCreds class to act as the base class for
      storing TLS credentials. This will be later subclassed to provide
      handling of anonymous and x509 credential types. The subclasses
      will be user creatable objects, so instances can be created &
      deleted via 'object-add' and 'object-del' QMP commands respectively,
      or via the -object command line arg.
      
      If the credentials cannot be initialized an error will be reported
      as a QMP reply, or on stderr respectively.
      
      The idea is to make it possible to represent and manage TLS
      credentials independently of the network service that is using
      them. This will enable multiple services to use the same set of
      credentials and minimize code duplication. A later patch will
      convert the current VNC server TLS code over to use this object.
      
      The representation of credentials will be functionally equivalent
      to that currently implemented in the VNC server with one exception.
      The new code has the ability to (optionally) load a pre-generated
      set of diffie-hellman parameters, if the file dh-params.pem exists,
      whereas the current VNC server will always generate them on startup.
      This is beneficial for admins who wish to avoid the (small) time
      sink of generating DH parameters at startup and/or avoid depleting
      entropy.
      
      Signed-off-by: default avatarDaniel P. Berrange <berrange@redhat.com>
      a090187d
Loading