Skip to content
Snippets Groups Projects
  1. Oct 12, 2020
  2. Sep 18, 2020
  3. Sep 10, 2020
  4. Sep 07, 2020
  5. Sep 02, 2020
  6. Aug 21, 2020
    • Marc-André Lureau's avatar
    • Paolo Bonzini's avatar
      libqemuutil, qapi, trace: convert to meson · a81df1b6
      Paolo Bonzini authored
      
      This shows how to do some "computations" in meson.build using its array
      and dictionary data structures, and also a basic usage of the sourceset
      module for conditional compilation.
      
      Notice the new "if have_system" part of util/meson.build, which fixes
      a bug in the old build system was buggy: util/dbus.c was built even for
      non-softmmu builds, but the dependency on -lgio was lost when the linking
      was done through libqemuutil.a.  Because all of its users required gio
      otherwise, the bug was hidden.  Meson instead propagates libqemuutil's
      dependencies down to its users, and shows the problem.
      
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      a81df1b6
    • Paolo Bonzini's avatar
      trace: switch position of headers to what Meson requires · 243af022
      Paolo Bonzini authored
      
      Meson doesn't enjoy the same flexibility we have with Make in choosing
      the include path.  In particular the tracing headers are using
      $(build_root)/$(<D).
      
      In order to keep the include directives unchanged,
      the simplest solution is to generate headers with patterns like
      "trace/trace-audio.h" and place forwarding headers in the source tree
      such that for example "audio/trace.h" includes "trace/trace-audio.h".
      
      This patch is too ugly to be applied to the Makefiles now.  It's only
      a way to separate the changes to the tracing header files from the
      Meson rewrite of the tracing logic.
      
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      243af022
  7. Jul 10, 2020
    • Markus Armbruster's avatar
      qom: Put name parameter before value / visitor parameter · 5325cc34
      Markus Armbruster authored
      
      The object_property_set_FOO() setters take property name and value in
      an unusual order:
      
          void object_property_set_FOO(Object *obj, FOO_TYPE value,
                                       const char *name, Error **errp)
      
      Having to pass value before name feels grating.  Swap them.
      
      Same for object_property_set(), object_property_get(), and
      object_property_parse().
      
      Convert callers with this Coccinelle script:
      
          @@
          identifier fun = {
              object_property_get, object_property_parse, object_property_set_str,
              object_property_set_link, object_property_set_bool,
              object_property_set_int, object_property_set_uint, object_property_set,
              object_property_set_qobject
          };
          expression obj, v, name, errp;
          @@
          -    fun(obj, v, name, errp)
          +    fun(obj, name, v, errp)
      
      Chokes on hw/arm/musicpal.c's lcd_refresh() with the unhelpful error
      message "no position information".  Convert that one manually.
      
      Fails to convert hw/arm/armsse.c, because Coccinelle gets confused by
      ARMSSE being used both as typedef and function-like macro there.
      Convert manually.
      
      Fails to convert hw/rx/rx-gdbsim.c, because Coccinelle gets confused
      by RXCPU being used both as typedef and function-like macro there.
      Convert manually.  The other files using RXCPU that way don't need
      conversion.
      
      Signed-off-by: default avatarMarkus Armbruster <armbru@redhat.com>
      Reviewed-by: default avatarEric Blake <eblake@redhat.com>
      Reviewed-by: default avatarVladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
      Message-Id: <20200707160613.848843-27-armbru@redhat.com>
      [Straightforwad conflict with commit 2336172d "audio: set default
      value for pcspk.iobase property" resolved]
      5325cc34
  8. Jul 06, 2020
  9. Jul 03, 2020
    • Philippe Mathieu-Daudé's avatar
      crypto/tls-cipher-suites: Produce fw_cfg consumable blob · 69699f30
      Philippe Mathieu-Daudé authored
      
      Since our format is consumable by the fw_cfg device,
      we can implement the FW_CFG_DATA_GENERATOR interface.
      
      Example of use to dump the cipher suites (if tracing enabled):
      
        $ qemu-system-x86_64 -S \
          -object tls-cipher-suites,id=mysuite1,priority=@SYSTEM \
          -fw_cfg name=etc/path/to/ciphers,gen_id=mysuite1 \
          -trace qcrypto\*
        1590664444.197123:qcrypto_tls_cipher_suite_priority priority: @SYSTEM
        1590664444.197219:qcrypto_tls_cipher_suite_info data=[0x13,0x02] version=TLS1.3 name=TLS_AES_256_GCM_SHA384
        1590664444.197228:qcrypto_tls_cipher_suite_info data=[0x13,0x03] version=TLS1.3 name=TLS_CHACHA20_POLY1305_SHA256
        1590664444.197233:qcrypto_tls_cipher_suite_info data=[0x13,0x01] version=TLS1.3 name=TLS_AES_128_GCM_SHA256
        1590664444.197236:qcrypto_tls_cipher_suite_info data=[0x13,0x04] version=TLS1.3 name=TLS_AES_128_CCM_SHA256
        1590664444.197240:qcrypto_tls_cipher_suite_info data=[0xc0,0x30] version=TLS1.2 name=TLS_ECDHE_RSA_AES_256_GCM_SHA384
        1590664444.197245:qcrypto_tls_cipher_suite_info data=[0xcc,0xa8] version=TLS1.2 name=TLS_ECDHE_RSA_CHACHA20_POLY1305
        1590664444.197250:qcrypto_tls_cipher_suite_info data=[0xc0,0x14] version=TLS1.0 name=TLS_ECDHE_RSA_AES_256_CBC_SHA1
        1590664444.197254:qcrypto_tls_cipher_suite_info data=[0xc0,0x2f] version=TLS1.2 name=TLS_ECDHE_RSA_AES_128_GCM_SHA256
        1590664444.197258:qcrypto_tls_cipher_suite_info data=[0xc0,0x13] version=TLS1.0 name=TLS_ECDHE_RSA_AES_128_CBC_SHA1
        1590664444.197261:qcrypto_tls_cipher_suite_info data=[0xc0,0x2c] version=TLS1.2 name=TLS_ECDHE_ECDSA_AES_256_GCM_SHA384
        1590664444.197266:qcrypto_tls_cipher_suite_info data=[0xcc,0xa9] version=TLS1.2 name=TLS_ECDHE_ECDSA_CHACHA20_POLY1305
        1590664444.197270:qcrypto_tls_cipher_suite_info data=[0xc0,0xad] version=TLS1.2 name=TLS_ECDHE_ECDSA_AES_256_CCM
        1590664444.197274:qcrypto_tls_cipher_suite_info data=[0xc0,0x0a] version=TLS1.0 name=TLS_ECDHE_ECDSA_AES_256_CBC_SHA1
        1590664444.197278:qcrypto_tls_cipher_suite_info data=[0xc0,0x2b] version=TLS1.2 name=TLS_ECDHE_ECDSA_AES_128_GCM_SHA256
        1590664444.197283:qcrypto_tls_cipher_suite_info data=[0xc0,0xac] version=TLS1.2 name=TLS_ECDHE_ECDSA_AES_128_CCM
        1590664444.197287:qcrypto_tls_cipher_suite_info data=[0xc0,0x09] version=TLS1.0 name=TLS_ECDHE_ECDSA_AES_128_CBC_SHA1
        1590664444.197291:qcrypto_tls_cipher_suite_info data=[0x00,0x9d] version=TLS1.2 name=TLS_RSA_AES_256_GCM_SHA384
        1590664444.197296:qcrypto_tls_cipher_suite_info data=[0xc0,0x9d] version=TLS1.2 name=TLS_RSA_AES_256_CCM
        1590664444.197300:qcrypto_tls_cipher_suite_info data=[0x00,0x35] version=TLS1.0 name=TLS_RSA_AES_256_CBC_SHA1
        1590664444.197304:qcrypto_tls_cipher_suite_info data=[0x00,0x9c] version=TLS1.2 name=TLS_RSA_AES_128_GCM_SHA256
        1590664444.197308:qcrypto_tls_cipher_suite_info data=[0xc0,0x9c] version=TLS1.2 name=TLS_RSA_AES_128_CCM
        1590664444.197312:qcrypto_tls_cipher_suite_info data=[0x00,0x2f] version=TLS1.0 name=TLS_RSA_AES_128_CBC_SHA1
        1590664444.197316:qcrypto_tls_cipher_suite_info data=[0x00,0x9f] version=TLS1.2 name=TLS_DHE_RSA_AES_256_GCM_SHA384
        1590664444.197320:qcrypto_tls_cipher_suite_info data=[0xcc,0xaa] version=TLS1.2 name=TLS_DHE_RSA_CHACHA20_POLY1305
        1590664444.197325:qcrypto_tls_cipher_suite_info data=[0xc0,0x9f] version=TLS1.2 name=TLS_DHE_RSA_AES_256_CCM
        1590664444.197329:qcrypto_tls_cipher_suite_info data=[0x00,0x39] version=TLS1.0 name=TLS_DHE_RSA_AES_256_CBC_SHA1
        1590664444.197333:qcrypto_tls_cipher_suite_info data=[0x00,0x9e] version=TLS1.2 name=TLS_DHE_RSA_AES_128_GCM_SHA256
        1590664444.197337:qcrypto_tls_cipher_suite_info data=[0xc0,0x9e] version=TLS1.2 name=TLS_DHE_RSA_AES_128_CCM
        1590664444.197341:qcrypto_tls_cipher_suite_info data=[0x00,0x33] version=TLS1.0 name=TLS_DHE_RSA_AES_128_CBC_SHA1
        1590664444.197345:qcrypto_tls_cipher_suite_count count: 29
      
      Signed-off-by: default avatarPhilippe Mathieu-Daudé <philmd@redhat.com>
      Reviewed-by: default avatarDaniel P. Berrangé <berrange@redhat.com>
      Acked-by: default avatarLaszlo Ersek <lersek@redhat.com>
      Message-Id: <20200623172726.21040-6-philmd@redhat.com>
      69699f30
    • Philippe Mathieu-Daudé's avatar
      crypto: Add tls-cipher-suites object · 993aec27
      Philippe Mathieu-Daudé authored
      
      On the host OS, various aspects of TLS operation are configurable.
      In particular it is possible for the sysadmin to control the TLS
      cipher/protocol algorithms that applications are permitted to use.
      
      * Any given crypto library has a built-in default priority list
        defined by the distro maintainer of the library package (or by
        upstream).
      
      * The "crypto-policies" RPM (or equivalent host OS package)
        provides a config file such as "/etc/crypto-policies/config",
        where the sysadmin can set a high level (library-independent)
        policy.
      
        The "update-crypto-policies --set" command (or equivalent) is
        used to translate the global policy to individual library
        representations, producing files such as
        "/etc/crypto-policies/back-ends/*.config". The generated files,
        if present, are loaded by the various crypto libraries to
        override their own built-in defaults.
      
        For example, the GNUTLS library may read
        "/etc/crypto-policies/back-ends/gnutls.config".
      
      * A management application (or the QEMU user) may overide the
        system-wide crypto-policies config via their own config, if
        they need to diverge from the former.
      
      Thus the priority order is "QEMU user config" > "crypto-policies
      system config" > "library built-in config".
      
      Introduce the "tls-cipher-suites" object for exposing the ordered
      list of permitted TLS cipher suites from the host side to the
      guest firmware, via fw_cfg. The list is represented as an array
      of bytes.
      
      The priority at which the host-side policy is retrieved is given
      by the "priority" property of the new object type. For example,
      "priority=@SYSTEM" may be used to refer to
      "/etc/crypto-policies/back-ends/gnutls.config" (given that QEMU
      uses GNUTLS).
      
      The firmware uses the IANA_TLS_CIPHER array for configuring
      guest-side TLS, for example in UEFI HTTPS Boot.
      
      [Description from Daniel P. Berrangé, edited by Laszlo Ersek.]
      
      Signed-off-by: default avatarPhilippe Mathieu-Daudé <philmd@redhat.com>
      Reviewed-by: default avatarDaniel P. Berrangé <berrange@redhat.com>
      Acked-by: default avatarLaszlo Ersek <lersek@redhat.com>
      Message-Id: <20200623172726.21040-2-philmd@redhat.com>
      993aec27
  10. Jun 15, 2020
  11. 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
  12. May 07, 2020
  13. Mar 11, 2020
  14. Dec 18, 2019
  15. Dec 17, 2019
Loading