Skip to content
Snippets Groups Projects
  1. May 26, 2021
  2. Jan 29, 2021
    • Daniel P. Berrangé's avatar
      os: deprecate the -enable-fips option and QEMU's FIPS enforcement · 16631029
      Daniel P. Berrangé authored
      
      The -enable-fips option was added a long time ago to prevent the use of
      single DES when VNC when FIPS mode is enabled. It should never have been
      added, because apps are supposed to unconditionally honour FIPS mode
      based on the '/proc/sys/crypto/fips_enabled' file contents.
      
      In addition there is more to achieving FIPS compliance than merely
      blocking use of certain algorithms. Those algorithms which are used
      need to perform self-tests at runtime.
      
      QEMU's built-in cryptography provider has no support for self-tests,
      and neither does the nettle library.
      
      If QEMU is required to be used in a FIPS enabled host, then it must be
      built with the libgcrypt library enabled, which will unconditionally
      enforce FIPS compliance in any algorithm usage.
      
      Thus there is no need to keep either the -enable-fips option in QEMU, or
      QEMU's internal FIPS checking methods.
      
      Reviewed-by: default avatarJohn Snow <jsnow@redhat.com>
      Reviewed-by: default avatarThomas Huth <thuth@redhat.com>
      Signed-off-by: default avatarDaniel P. Berrangé <berrange@redhat.com>
      16631029
  3. Sep 30, 2020
  4. Sep 16, 2020
  5. Aug 21, 2020
  6. Jul 21, 2020
  7. Jul 13, 2020
  8. Dec 17, 2019
  9. Aug 16, 2019
    • Markus Armbruster's avatar
      sysemu: Split sysemu/runstate.h off sysemu/sysemu.h · 54d31236
      Markus Armbruster authored
      
      sysemu/sysemu.h is a rather unfocused dumping ground for stuff related
      to the system-emulator.  Evidence:
      
      * It's included widely: in my "build everything" tree, changing
        sysemu/sysemu.h still triggers a recompile of some 1100 out of 6600
        objects (not counting tests and objects that don't depend on
        qemu/osdep.h, down from 5400 due to the previous two commits).
      
      * It pulls in more than a dozen additional headers.
      
      Split stuff related to run state management into its own header
      sysemu/runstate.h.
      
      Touching sysemu/sysemu.h now recompiles some 850 objects.  qemu/uuid.h
      also drops from 1100 to 850, and qapi/qapi-types-run-state.h from 4400
      to 4200.  Touching new sysemu/runstate.h recompiles some 500 objects.
      
      Since I'm touching MAINTAINERS to add sysemu/runstate.h anyway, also
      add qemu/main-loop.h.
      
      Suggested-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarMarkus Armbruster <armbru@redhat.com>
      Message-Id: <20190812052359.30071-30-armbru@redhat.com>
      Reviewed-by: default avatarAlex Bennée <alex.bennee@linaro.org>
      [Unbreak OS-X build]
      54d31236
  10. Jun 12, 2019
    • Markus Armbruster's avatar
      Include qemu-common.h exactly where needed · a8d25326
      Markus Armbruster authored
      
      No header includes qemu-common.h after this commit, as prescribed by
      qemu-common.h's file comment.
      
      Signed-off-by: default avatarMarkus Armbruster <armbru@redhat.com>
      Message-Id: <20190523143508.25387-5-armbru@redhat.com>
      [Rebased with conflicts resolved automatically, except for
      include/hw/arm/xlnx-zynqmp.h hw/arm/nrf51_soc.c hw/arm/msf2-soc.c
      block/qcow2-refcount.c block/qcow2-cluster.c block/qcow2-cache.c
      target/arm/cpu.h target/lm32/cpu.h target/m68k/cpu.h target/mips/cpu.h
      target/moxie/cpu.h target/nios2/cpu.h target/openrisc/cpu.h
      target/riscv/cpu.h target/tilegx/cpu.h target/tricore/cpu.h
      target/unicore32/cpu.h target/xtensa/cpu.h; bsd-user/main.c and
      net/tap-bsd.c fixed up]
      a8d25326
  11. Oct 02, 2018
    • Marc-André Lureau's avatar
      util: add qemu_write_pidfile() · 9e6bdef2
      Marc-André Lureau authored
      
      There are variants of qemu_create_pidfile() in qemu-pr-helper and
      qemu-ga. Let's have a common implementation in libqemuutil.
      
      The code is initially based from pr-helper write_pidfile(), with
      various improvements and suggestions from Daniel Berrangé:
      
        QEMU will leave the pidfile existing on disk when it exits which
        initially made me think it avoids the deletion race. The app
        managing QEMU, however, may well delete the pidfile after it has
        seen QEMU exit, and even if the app locks the pidfile before
        deleting it, there is still a race.
      
        eg consider the following sequence
      
              QEMU 1        libvirtd        QEMU 2
      
        1.    lock(pidfile)
      
        2.    exit()
      
        3.                 open(pidfile)
      
        4.                 lock(pidfile)
      
        5.                                  open(pidfile)
      
        6.                 unlink(pidfile)
      
        7.                 close(pidfile)
      
        8.                                  lock(pidfile)
      
        IOW, at step 8 the new QEMU has successfully acquired the lock, but
        the pidfile no longer exists on disk because it was deleted after
        the original QEMU exited.
      
        While we could just say no external app should ever delete the
        pidfile, I don't think that is satisfactory as people don't read
        docs, and admins don't like stale pidfiles being left around on
        disk.
      
        To make this robust, I think we might want to copy libvirt's
        approach to pidfile acquisition which runs in a loop and checks that
        the file on disk /after/ acquiring the lock matches the file that
        was locked. Then we could in fact safely let QEMU delete its own
        pidfiles on clean exit..
      
      Signed-off-by: default avatarMarc-André Lureau <marcandre.lureau@redhat.com>
      Message-Id: <20180831145314.14736-2-marcandre.lureau@redhat.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      9e6bdef2
  12. Aug 31, 2018
  13. May 08, 2018
  14. Apr 26, 2018
  15. Oct 16, 2017
  16. Aug 08, 2017
  17. Jul 17, 2016
  18. Jun 16, 2016
  19. Mar 22, 2016
  20. Feb 22, 2016
  21. Feb 04, 2016
  22. Apr 01, 2015
    • Paolo Bonzini's avatar
      rcu: do not create thread in pthread_atfork callback · a59629fc
      Paolo Bonzini authored
      
      If QEMU forks after the CPU threads have been created, qemu_mutex_lock_iothread
      will not be able to do qemu_cpu_kick_thread.  There is no solution other than
      assuming that forks after the CPU threads have been created will end up in an
      exec.  Forks before the CPU threads have been created (such as -daemonize)
      have to call rcu_after_fork manually.
      
      Notably, the oxygen theme for GTK+ forks and shows a "No such process" error
      without this patch.
      
      This patch can be reverted once the iothread loses the "kick the TCG thread"
      magic.
      
      User-mode emulation does not use the iothread, so it can also call
      rcu_after_fork.
      
      Reported by: Dr. David Alan Gilbert <dgilbert@redhat.com>
      Tested by: Dr. David Alan Gilbert <dgilbert@redhat.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      a59629fc
  23. Nov 02, 2014
  24. Sep 26, 2014
  25. Mar 13, 2014
  26. Feb 20, 2014
  27. Apr 22, 2013
  28. Dec 19, 2012
  29. Oct 05, 2012
Loading