Skip to content
Snippets Groups Projects
  1. Oct 13, 2020
  2. Sep 16, 2020
  3. 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
  4. Jul 03, 2019
    • Kashyap Chamarthy's avatar
      VirtIO-RNG: Update default entropy source to `/dev/urandom` · a2230bd7
      Kashyap Chamarthy authored
      When QEMU exposes a VirtIO-RNG device to the guest, that device needs a
      source of entropy, and that source needs to be "non-blocking", like
      `/dev/urandom`.  However, currently QEMU defaults to the problematic
      `/dev/random`, which on Linux is "blocking" (as in, it waits until
      sufficient entropy is available).
      
      Why prefer `/dev/urandom` over `/dev/random`?
      ---------------------------------------------
      
      The man pages of urandom(4) and random(4) state:
      
          "The /dev/random device is a legacy interface which dates back to a
          time where the cryptographic primitives used in the implementation
          of /dev/urandom were not widely trusted.  It will return random
          bytes only within the estimated number of bits of fresh noise in the
          entropy pool, blocking if necessary.  /dev/random is suitable for
          applications that need high quality randomness, and can afford
          indeterminate delays."
      
      Further, the "Usage" section of the said man pages state:
      
          "The /dev/random interface is considered a legacy interface, and
          /dev/urandom is preferred and sufficient in all use cases, with the
          exception of applications which require randomness during early boot
          time; for these applications, getrandom(2) must be used instead,
          because it will block until the entropy pool is initialized.
      
          "If a seed file is saved across reboots as recommended below (all
          major Linux distributions have done this since 2000 at least), the
          output is cryptographically secure against attackers without local
          root access as soon as it is reloaded in the boot sequence, and
          perfectly adequate for network encryption session keys.  Since reads
          from /dev/random may block, users will usually want to open it in
          nonblocking mode (or perform a read with timeout), and provide some
          sort of user notification if the desired entropy is not immediately
          available."
      
      And refer to random(7) for a comparison of `/dev/random` and
      `/dev/urandom`.
      
      What about other OSes?
      ----------------------
      
      `/dev/urandom` exists and works on OS-X, FreeBSD, DragonFlyBSD, NetBSD
      and OpenBSD, which cover all the non-Linux platforms we explicitly
      support, aside from Windows.
      
      On Windows `/dev/random` doesn't work either so we don't regress.
      This is actually another argument in favour of using the newly
      proposed 'rng-builtin' backend by default, as that will work on
      Windows.
      
          - - -
      
      Given the above, change the entropy source for VirtIO-RNG device to
      `/dev/urandom`.
      
      Related discussion in these[1][2] past threads.
      
      [1] https://lists.nongnu.org/archive/html/qemu-devel/2018-06/msg08335.html
          -- "RNG: Any reason QEMU doesn't default to `/dev/urandom`?"
      [2] https://lists.nongnu.org/archive/html/qemu-devel/2018-09/msg02724.html
      
      
          -- "[RFC] Virtio RNG: Consider changing the default entropy source to
             /dev/urandom"
      
      Signed-off-by: default avatarKashyap Chamarthy <kchamart@redhat.com>
      Reviewed-by: default avatarDaniel P. Berrangé <berrange@redhat.com>
      Reviewed-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
      Reviewed-by: default avatarMarkus Armbruster <armbru@redhat.com>
      Signed-off-by: default avatarLaurent Vivier <lvivier@redhat.com>
      Message-Id: <20190529143106.11789-2-lvivier@redhat.com>
      Signed-off-by: default avatarLaurent Vivier <laurent@vivier.eu>
      a2230bd7
  5. Jun 12, 2019
  6. May 23, 2016
  7. 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
  8. Mar 08, 2016
  9. Mar 03, 2016
    • Ladi Prosek's avatar
      rng: add request queue support to rng-random · 60253ed1
      Ladi Prosek authored
      
      Requests are now created in the RngBackend parent class and the
      code path is shared by both rng-egd and rng-random.
      
      This commit fixes the rng-random implementation which processed
      only one request at a time and simply discarded all but the most
      recent one. In the guest this manifested as delayed completion
      of reads from virtio-rng, i.e. a read was completed only after
      another read was issued.
      
      By switching rng-random to use the same request queue as rng-egd,
      the unsafe stack-based allocation of the entropy buffer is
      eliminated and replaced with g_malloc.
      
      Signed-off-by: default avatarLadi Prosek <lprosek@redhat.com>
      Reviewed-by: default avatarAmit Shah <amit.shah@redhat.com>
      Message-Id: <1456994238-9585-5-git-send-email-lprosek@redhat.com>
      Signed-off-by: default avatarAmit Shah <amit.shah@redhat.com>
      60253ed1
  10. Feb 04, 2016
  11. Jun 22, 2015
  12. Dec 10, 2014
  13. Jun 24, 2014
  14. Jan 06, 2014
  15. Jun 17, 2013
  16. Apr 16, 2013
  17. Apr 15, 2013
  18. Mar 08, 2013
  19. Jan 10, 2013
    • Andreas Färber's avatar
      Make all static TypeInfos const · 8c43a6f0
      Andreas Färber authored
      
      Since 39bffca2 (qdev: register all
      types natively through QEMU Object Model), TypeInfo as used in
      the common, non-iterative pattern is no longer amended with information
      and should therefore be const.
      
      Fix the documented QOM examples:
      
       sed -i 's/static TypeInfo/static const TypeInfo/g' include/qom/object.h
      
      Since frequently the wrong examples are being copied by contributors of
      new devices, fix all types in the tree:
      
       sed -i 's/^static TypeInfo/static const TypeInfo/g' */*.c
       sed -i 's/^static TypeInfo/static const TypeInfo/g' */*/*.c
      
      This also avoids to piggy-back these changes onto real functional
      changes or other refactorings.
      
      Signed-off-by: default avatarAndreas Färber <afaerber@suse.de>
      Signed-off-by: default avatarAnthony Liguori <aliguori@us.ibm.com>
      8c43a6f0
  20. Dec 19, 2012
  21. Nov 16, 2012
    • Anthony Liguori's avatar
      rng-random: add an RNG backend that uses /dev/random (v3) · 5c74521d
      Anthony Liguori authored
      
      The filename can be overridden but it expects a non-blocking source of entropy.
      A typical invocation would be:
      
      qemu -object rng-random,id=rng0 -device virtio-rng-pci,rng=rng0
      
      This can also be used with /dev/urandom by using the command line:
      
      qemu -object rng-random,filename=/dev/urandom,id=rng0 \
           -device virtio-rng-pci,rng=rng0
      
      Signed-off-by: default avatarAnthony Liguori <aliguori@us.ibm.com>
      ---
      v1 -> v2
       - merged header split patch into this one
      v2 -> v3
       - bug fix in rng-random (Paolo)
      5c74521d
Loading