All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 0/1] MAINTAINERS: add security quotient field
@ 2020-07-14  8:36 P J P
  2020-07-14  8:36 ` [PATCH 1/1] MAINTAINERS: introduce cve or " P J P
  2020-07-14  9:46 ` [PATCH 0/1] MAINTAINERS: add " Michael S. Tsirkin
  0 siblings, 2 replies; 28+ messages in thread
From: P J P @ 2020-07-14  8:36 UTC (permalink / raw)
  To: Michael S . Tsirkin, Daniel P . Berrange
  Cc: Kevin Wolf, Peter Maydell, Stefano Stabellini, Prasad J Pandit,
	Christian Schoenebeck, Michael Roth, QEMU Developers, Greg Kurz,
	Stefan Hajnoczi, Paolo Bonzini

From: Prasad J Pandit <pjp@fedoraproject.org>

Hello,

QEMU supports numerous virtualisation and emulation use cases.
It offers many features to support guest's function(s).

All of these use cases and features are not always security relevant.
Because some maybe used in trusted environments only. Some may still
be in experimental stage. While other could be very old and not
used or maintained actively.

Recently we received multiple security issue reports against VVFAT
and VirtFS host directory sharing system. After discussing with the
respective maintainers, it turned out that

* VVFAT -> https://bugs.launchpad.net/qemu/+bug/1883083
  VVFAT is quite old and is available for testing purposes only.
  Ie. It is not suitable for production environments.

* VirtFS/9pfs -> https://wiki.qemu.org/Documentation/9psetup
  VirtFS implementation though better, it is most commonly used for
  automated testing under sand-boxed server environments, ie. no
  malicious party there. It is also not mature enough for cloud services.
  It is supported on 'Odd Fixes' basis atm.

So these turned out to be issues which can be fixed as regular bugs.

For security bug analysis we generally consider use cases wherein
QEMU is used in conjunction with the KVM hypervisor, which enables
guest to use hardware processor's virtualisation features.

This patch introduces the CVE (or Security or Trust) Quotient field
in the MAINTAINERS file. It tries to capture the security sensitivity
pertaining to a feature or section of the QEMU's code base.

It indicates whether a potential issue should be treated as a security
one OR it could be fixed as a regular non-security bug.

    If Quotient == High, triage issues as potential security ones.
    if Quotient == Low,  triage issues as regular non-security bugs.

I have tagged each section in the MAINTAINERS file as High or Low on best
guess basis. I request respective maintainers to kindly review it please.

If you have any inputs/suggestions, I'd really appreciate them.

Thank you.
--
Prasad J Pandit (1):
  MAINTAINERS: introduce cve or security quotient field

 MAINTAINERS | 324 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 324 insertions(+)

--
2.26.2



^ permalink raw reply	[flat|nested] 28+ messages in thread
* [PATCH 1/1] MAINTAINERS: introduce cve or security quotient field
  2020-07-14  8:36 [PATCH 0/1] MAINTAINERS: add security quotient field P J P
@ 2020-07-14  8:36 ` P J P
  2020-07-14  9:42   ` Peter Maydell
                     ` (3 more replies)
  2020-07-14  9:46 ` [PATCH 0/1] MAINTAINERS: add " Michael S. Tsirkin
  1 sibling, 4 replies; 28+ messages in thread
From: P J P @ 2020-07-14  8:36 UTC (permalink / raw)
  To: Michael S . Tsirkin, Daniel P . Berrange
  Cc: Kevin Wolf, Peter Maydell, Stefano Stabellini, Prasad J Pandit,
	Christian Schoenebeck, Michael Roth, QEMU Developers, Greg Kurz,
	Stefan Hajnoczi, Paolo Bonzini

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=y, Size: 59954 bytes --]

From: Prasad J Pandit <pjp@fedoraproject.org>

QEMU supports numerous virtualisation and emulation use cases.
It also offers many features to support guest's function(s).

All of these use cases and features are not always security relevant.
Because some maybe used in trusted environments only. Some may still
be in experimental stage. While other could be very old and not
used or maintained actively.

For security bug analysis we generally consider use cases wherein
QEMU is used in conjunction with the KVM hypervisor, which enables
guest to use hardware processor's virtualisation features.

The CVE (or Security or Trust) Quotient field tries to capture this
sensitivity pertaining to a feature or section of the code.

It indicates whether a potential issue should be treated as a security
one OR it could be fixed as a regular non-security bug.

Suggested-by: Daniel P. Berrange <berrange@redhat.com>
Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org>
---
 MAINTAINERS | 324 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 324 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index fe8139f367..badf1dab6e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -33,6 +33,14 @@ Descriptions of section entries:
 	   Obsolete:	Old code. Something tagged obsolete generally means
 			it has been replaced by a better system and you
 			should be using that.
+	C: CVE/Security/Trust Quotient
+	   H:High - Feature (or code) is meant to be safe and used by untrusted
+	            guests. So any potential security issue must be processed with
+	            due care and be considered as a CVE issue.
+	   L:Low  - Feature (or code) is not meant to be safe OR is experimental
+	            OR is used in trusted environments only OR is not well
+	            maintained. So any potential security issue can be processed
+	            and fixed as regular non-security bug. No need for a CVE.
 	F: Files and directories with wildcard patterns.
 	   A trailing slash includes all files and subdirectory files.
 	   F:	drivers/net/	all files in and below drivers/net
@@ -87,6 +95,7 @@ S390 general architecture support
 M: Cornelia Huck <cohuck@redhat.com>
 M: Thomas Huth <thuth@redhat.com>
 S: Supported
+C: High
 F: default-configs/s390x-softmmu.mak
 F: gdb-xml/s390*.xml
 F: hw/char/sclp*.[hc]
@@ -115,6 +124,7 @@ Overall TCG CPUs
 M: Richard Henderson <rth@twiddle.net>
 R: Paolo Bonzini <pbonzini@redhat.com>
 S: Maintained
+C: Low
 F: softmmu/cpus.c
 F: cpus-common.c
 F: exec.c
@@ -134,6 +144,7 @@ M: Aurelien Jarno <aurelien@aurel32.net>
 M: Peter Maydell <peter.maydell@linaro.org>
 M: Alex Bennée <alex.bennee@linaro.org>
 S: Maintained
+C: Low
 F: fpu/
 F: include/fpu/
 F: tests/fp/
@@ -141,6 +152,7 @@ F: tests/fp/
 Alpha TCG CPUs
 M: Richard Henderson <rth@twiddle.net>
 S: Maintained
+C: Low
 F: target/alpha/
 F: tests/tcg/alpha/
 F: disas/alpha.c
@@ -149,6 +161,7 @@ ARM TCG CPUs
 M: Peter Maydell <peter.maydell@linaro.org>
 L: qemu-arm@nongnu.org
 S: Maintained
+C: Low
 F: target/arm/
 F: tests/tcg/arm/
 F: tests/tcg/aarch64/
@@ -164,6 +177,7 @@ ARM SMMU
 M: Eric Auger <eric.auger@redhat.com>
 L: qemu-arm@nongnu.org
 S: Maintained
+C: High
 F: hw/arm/smmu*
 F: include/hw/arm/smmu*
 
@@ -171,6 +185,7 @@ AVR TCG CPUs
 M: Michael Rolnik <mrolnik@gmail.com>
 R: Sarah Harris <S.E.Harris@kent.ac.uk>
 S: Maintained
+C: Low
 F: gdb-xml/avr-cpu.xml
 F: target/avr/
 F: tests/acceptance/machine_avr6.py
@@ -178,6 +193,7 @@ F: tests/acceptance/machine_avr6.py
 CRIS TCG CPUs
 M: Edgar E. Iglesias <edgar.iglesias@gmail.com>
 S: Maintained
+C: Low
 F: target/cris/
 F: hw/cris/
 F: include/hw/cris/
@@ -187,6 +203,7 @@ F: disas/cris.c
 HPPA (PA-RISC) TCG CPUs
 M: Richard Henderson <rth@twiddle.net>
 S: Maintained
+C: Low
 F: target/hppa/
 F: hw/hppa/
 F: disas/hppa.c
@@ -196,6 +213,7 @@ F: include/hw/net/lasi_82596.h
 LM32 TCG CPUs
 R: Michael Walle <michael@walle.cc>
 S: Orphan
+C: Low
 F: target/lm32/
 F: disas/lm32.c
 F: hw/lm32/
@@ -209,12 +227,14 @@ F: tests/tcg/lm32/
 M68K TCG CPUs
 M: Laurent Vivier <laurent@vivier.eu>
 S: Maintained
+C: Low
 F: target/m68k/
 F: disas/m68k.c
 
 MicroBlaze TCG CPUs
 M: Edgar E. Iglesias <edgar.iglesias@gmail.com>
 S: Maintained
+C: Low
 F: target/microblaze/
 F: hw/microblaze/
 F: disas/microblaze.c
@@ -224,6 +244,7 @@ M: Aleksandar Markovic <aleksandar.qemu.devel@gmail.com>
 R: Aurelien Jarno <aurelien@aurel32.net>
 R: Aleksandar Rikalo <aleksandar.rikalo@syrmia.com>
 S: Maintained
+C: Low
 F: target/mips/
 F: default-configs/*mips*
 F: disas/*mips*
@@ -244,6 +265,7 @@ K: ^Subject:.*(?i)mips
 Moxie TCG CPUs
 M: Anthony Green <green@moxielogic.com>
 S: Maintained
+C: Low
 F: target/moxie/
 F: disas/moxie.c
 F: hw/moxie/
@@ -253,6 +275,7 @@ NiosII TCG CPUs
 M: Chris Wulff <crwulff@gmail.com>
 M: Marek Vasut <marex@denx.de>
 S: Maintained
+C: Low
 F: target/nios2/
 F: hw/nios2/
 F: hw/intc/nios2_iic.c
@@ -262,6 +285,7 @@ F: default-configs/nios2-softmmu.mak
 OpenRISC TCG CPUs
 M: Stafford Horne <shorne@gmail.com>
 S: Odd Fixes
+C: Low
 F: target/openrisc/
 F: hw/openrisc/
 F: tests/tcg/openrisc/
@@ -270,6 +294,7 @@ PowerPC TCG CPUs
 M: David Gibson <david@gibson.dropbear.id.au>
 L: qemu-ppc@nongnu.org
 S: Maintained
+C: High
 F: target/ppc/
 F: hw/ppc/
 F: include/hw/ppc/
@@ -282,6 +307,7 @@ M: Sagar Karandikar <sagark@eecs.berkeley.edu>
 M: Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
 L: qemu-riscv@nongnu.org
 S: Supported
+C: Low
 F: target/riscv/
 F: hw/riscv/
 F: include/hw/riscv/
@@ -291,12 +317,14 @@ F: linux-user/host/riscv64/
 RENESAS RX CPUs
 M: Yoshinori Sato <ysato@users.sourceforge.jp>
 S: Maintained
+C: Low
 F: target/rx/
 
 S390 TCG CPUs
 M: Richard Henderson <rth@twiddle.net>
 M: David Hildenbrand <david@redhat.com>
 S: Maintained
+C: High
 F: target/s390x/
 F: hw/s390x/
 F: disas/s390.c
@@ -306,6 +334,7 @@ L: qemu-s390x@nongnu.org
 SH4 TCG CPUs
 M: Yoshinori Sato <ysato@users.sourceforge.jp>
 S: Odd Fixes
+C: Low
 F: target/sh4/
 F: hw/sh4/
 F: disas/sh4.c
@@ -315,6 +344,7 @@ SPARC TCG CPUs
 M: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
 M: Artyom Tarasenko <atar4qemu@gmail.com>
 S: Maintained
+C: Low
 F: target/sparc/
 F: hw/sparc/
 F: hw/sparc64/
@@ -324,6 +354,7 @@ F: disas/sparc.c
 UniCore32 TCG CPUs
 M: Guan Xuetao <gxt@mprc.pku.edu.cn>
 S: Maintained
+C: Low
 F: target/unicore32/
 F: hw/unicore32/
 F: include/hw/unicore32/
@@ -333,6 +364,7 @@ M: Paolo Bonzini <pbonzini@redhat.com>
 M: Richard Henderson <rth@twiddle.net>
 M: Eduardo Habkost <ehabkost@redhat.com>
 S: Maintained
+C: High
 F: target/i386/
 F: tests/tcg/i386/
 F: tests/tcg/x86_64/
@@ -345,6 +377,7 @@ Xtensa TCG CPUs
 M: Max Filippov <jcmvbkbc@gmail.com>
 W: http://wiki.osll.ru/doku.php?id=etc:users:jcmvbkbc:qemu-target-xtensa
 S: Maintained
+C: Low
 F: target/xtensa/
 F: hw/xtensa/
 F: tests/tcg/xtensa/
@@ -355,6 +388,7 @@ F: default-configs/xtensa*.mak
 TriCore TCG CPUs
 M: Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
 S: Maintained
+C: Low
 F: target/tricore/
 F: hw/tricore/
 F: include/hw/tricore/
@@ -362,6 +396,7 @@ F: include/hw/tricore/
 Multiarch Linux User Tests
 M: Alex Bennée <alex.bennee@linaro.org>
 S: Maintained
+C: Low
 F: tests/tcg/multiarch/
 
 Guest CPU Cores (KVM)
@@ -370,6 +405,7 @@ Overall KVM CPUs
 M: Paolo Bonzini <pbonzini@redhat.com>
 L: kvm@vger.kernel.org
 S: Supported
+C: High
 F: */*/kvm*
 F: accel/kvm/
 F: accel/stubs/kvm-stub.c
@@ -381,16 +417,19 @@ ARM KVM CPUs
 M: Peter Maydell <peter.maydell@linaro.org>
 L: qemu-arm@nongnu.org
 S: Maintained
+C: High
 F: target/arm/kvm.c
 
 MIPS KVM CPUs
 M: Aleksandar Markovic <aleksandar.qemu.devel@gmail.com>
 S: Odd Fixes
+C: Low
 F: target/mips/kvm.c
 
 PPC KVM CPUs
 M: David Gibson <david@gibson.dropbear.id.au>
 S: Maintained
+C: High
 F: target/ppc/kvm.c
 
 S390 KVM CPUs
@@ -398,6 +437,7 @@ M: Halil Pasic <pasic@linux.ibm.com>
 M: Cornelia Huck <cohuck@redhat.com>
 M: Christian Borntraeger <borntraeger@de.ibm.com>
 S: Supported
+C: High
 F: target/s390x/kvm.c
 F: target/s390x/kvm_s390x.h
 F: target/s390x/kvm-stub.c
@@ -421,6 +461,7 @@ M: Paolo Bonzini <pbonzini@redhat.com>
 M: Marcelo Tosatti <mtosatti@redhat.com>
 L: kvm@vger.kernel.org
 S: Supported
+C: High
 F: target/i386/kvm.c
 F: scripts/kvm/vmxcap
 
@@ -430,6 +471,7 @@ Overall
 M: Richard Henderson <rth@twiddle.net>
 R: Paolo Bonzini <pbonzini@redhat.com>
 S: Maintained
+C: Low
 F: include/sysemu/accel.h
 F: accel/accel.c
 F: accel/Makefile.objs
@@ -440,6 +482,7 @@ M: Cameron Esfahani <dirty@apple.com>
 M: Roman Bolshakov <r.bolshakov@yadro.com>
 W: https://wiki.qemu.org/Features/HVF
 S: Maintained
+C: Low
 F: accel/stubs/hvf-stub.c
 F: target/i386/hvf/
 F: include/sysemu/hvf.h
@@ -447,6 +490,7 @@ F: include/sysemu/hvf.h
 WHPX CPUs
 M: Sunil Muthuswamy <sunilmut@microsoft.com>
 S: Supported
+C: Low
 F: target/i386/whpx-all.c
 F: target/i386/whp-dispatch.h
 F: accel/stubs/whpx-stub.c
@@ -460,6 +504,7 @@ M: Anthony Perard <anthony.perard@citrix.com>
 M: Paul Durrant <paul@xen.org>
 L: xen-devel@lists.xenproject.org
 S: Supported
+C: High
 F: */xen*
 F: accel/xen/*
 F: hw/9pfs/xen-9p*
@@ -486,6 +531,7 @@ M: Colin Xu <colin.xu@intel.com>
 L: haxm-team@intel.com
 W: https://github.com/intel/haxm/issues
 S: Maintained
+C: Low
 F: accel/stubs/hax-stub.c
 F: include/sysemu/hax.h
 F: target/i386/hax-*
@@ -497,12 +543,14 @@ M: Michael S. Tsirkin <mst@redhat.com>
 M: Cornelia Huck <cohuck@redhat.com>
 M: Paolo Bonzini <pbonzini@redhat.com>
 S: Maintained
+C: High
 F: linux-headers/
 F: scripts/update-linux-headers.sh
 
 POSIX
 M: Paolo Bonzini <pbonzini@redhat.com>
 S: Maintained
+C: High
 F: os-posix.c
 F: include/sysemu/os-posix.h
 F: util/*posix*.c
@@ -511,16 +559,19 @@ F: include/qemu/*posix*.h
 NETBSD
 M: Kamil Rytarowski <kamil@netbsd.org>
 S: Maintained
+C: High
 K: ^Subject:.*(?i)NetBSD
 
 OPENBSD
 M: Brad Smith <brad@comstyle.com>
 S: Maintained
+C: High
 K: ^Subject:.*(?i)OpenBSD
 
 W32, W64
 M: Stefan Weil <sw@weilnetz.de>
 S: Maintained
+C: High
 F: *win32*
 F: */*win32*
 F: include/*/*win32*
@@ -531,6 +582,7 @@ Alpha Machines
 --------------
 M: Richard Henderson <rth@twiddle.net>
 S: Maintained
+C: Low
 F: hw/alpha/
 F: hw/isa/smc37c669-superio.c
 F: tests/tcg/alpha/system/
@@ -542,6 +594,7 @@ M: Beniamino Galvani <b.galvani@gmail.com>
 M: Peter Maydell <peter.maydell@linaro.org>
 L: qemu-arm@nongnu.org
 S: Odd Fixes
+C: Low
 F: hw/*/allwinner*
 F: include/hw/*/allwinner*
 F: hw/arm/cubieboard.c
@@ -550,6 +603,7 @@ Allwinner-h3
 M: Niek Linnenbank <nieklinnenbank@gmail.com>
 L: qemu-arm@nongnu.org
 S: Maintained
+C: Low
 F: hw/*/allwinner-h3*
 F: include/hw/*/allwinner-h3*
 F: hw/arm/orangepi.c
@@ -559,6 +613,7 @@ ARM PrimeCell and CMSDK devices
 M: Peter Maydell <peter.maydell@linaro.org>
 L: qemu-arm@nongnu.org
 S: Maintained
+C: Low
 F: hw/char/pl011.c
 F: include/hw/char/pl011.h
 F: hw/display/pl110*
@@ -593,6 +648,7 @@ ARM cores
 M: Peter Maydell <peter.maydell@linaro.org>
 L: qemu-arm@nongnu.org
 S: Maintained
+C: High
 F: hw/intc/arm*
 F: hw/intc/gic_internal.h
 F: hw/misc/a9scu.c
@@ -614,6 +670,7 @@ M: Igor Mitsyanko <i.mitsyanko@gmail.com>
 M: Peter Maydell <peter.maydell@linaro.org>
 L: qemu-arm@nongnu.org
 S: Odd Fixes
+C: Low
 F: hw/*/exynos*
 F: include/hw/arm/exynos4210.h
 
@@ -622,6 +679,7 @@ M: Rob Herring <robh@kernel.org>
 M: Peter Maydell <peter.maydell@linaro.org>
 L: qemu-arm@nongnu.org
 S: Odd Fixes
+C: Low
 F: hw/arm/highbank.c
 F: hw/net/xgmac.c
 
@@ -630,6 +688,7 @@ M: Antony Pavlov <antonynpavlov@gmail.com>
 M: Peter Maydell <peter.maydell@linaro.org>
 L: qemu-arm@nongnu.org
 S: Odd Fixes
+C: Low
 F: include/hw/arm/digic.h
 F: hw/*/digic*
 F: include/hw/*/digic*
@@ -640,6 +699,7 @@ M: Anup Patel <anup.patel@wdc.com>
 M: Alistair Francis <Alistair.Francis@wdc.com>
 L: qemu-riscv@nongnu.org
 S: Maintained
+C: Low
 F: hw/rtc/goldfish_rtc.c
 F: include/hw/rtc/goldfish_rtc.h
 
@@ -648,6 +708,7 @@ M: Peter Maydell <peter.maydell@linaro.org>
 R: Philippe Mathieu-Daudé <f4bug@amsat.org>
 L: qemu-arm@nongnu.org
 S: Odd Fixes
+C: Low
 F: hw/arm/gumstix.c
 
 i.MX25 PDK
@@ -655,6 +716,7 @@ M: Peter Maydell <peter.maydell@linaro.org>
 R: Jean-Christophe Dubois <jcd@tribudubois.net>
 L: qemu-arm@nongnu.org
 S: Odd Fixes
+C: Low
 F: hw/arm/fsl-imx25.c
 F: hw/arm/imx25_pdk.c
 F: hw/misc/imx25_ccm.c
@@ -668,6 +730,7 @@ M: Peter Chubb <peter.chubb@nicta.com.au>
 M: Peter Maydell <peter.maydell@linaro.org>
 L: qemu-arm@nongnu.org
 S: Odd Fixes
+C: Low
 F: hw/arm/kzm.c
 F: hw/*/imx_*
 F: hw/*/*imx31*
@@ -678,6 +741,7 @@ Integrator CP
 M: Peter Maydell <peter.maydell@linaro.org>
 L: qemu-arm@nongnu.org
 S: Maintained
+C: Low
 F: hw/arm/integratorcp.c
 F: hw/misc/arm_integrator_debug.c
 F: include/hw/misc/arm_integrator_debug.h
@@ -689,6 +753,7 @@ M: Peter Maydell <peter.maydell@linaro.org>
 R: Jean-Christophe Dubois <jcd@tribudubois.net>
 L: qemu-arm@nongnu.org
 S: Odd Fixes
+C: Low
 F: hw/arm/mcimx6ul-evk.c
 F: hw/arm/fsl-imx6ul.c
 F: hw/misc/imx6ul_ccm.c
@@ -700,6 +765,7 @@ M: Peter Maydell <peter.maydell@linaro.org>
 R: Andrey Smirnov <andrew.smirnov@gmail.com>
 L: qemu-arm@nongnu.org
 S: Odd Fixes
+C: Low
 F: hw/arm/mcimx7d-sabre.c
 F: hw/arm/fsl-imx7.c
 F: hw/misc/imx7_*.c
@@ -712,6 +778,7 @@ MPS2
 M: Peter Maydell <peter.maydell@linaro.org>
 L: qemu-arm@nongnu.org
 S: Maintained
+C: Low
 F: hw/arm/mps2.c
 F: hw/arm/mps2-tz.c
 F: hw/misc/mps2-*.c
@@ -734,6 +801,7 @@ Musca
 M: Peter Maydell <peter.maydell@linaro.org>
 L: qemu-arm@nongnu.org
 S: Maintained
+C: Low
 F: hw/arm/musca.c
 F: docs/system/arm/musca.rst
 
@@ -742,6 +810,7 @@ M: Jan Kiszka <jan.kiszka@web.de>
 M: Peter Maydell <peter.maydell@linaro.org>
 L: qemu-arm@nongnu.org
 S: Odd Fixes
+C: Low
 F: hw/arm/musicpal.c
 F: docs/system/arm/musicpal.rst
 
@@ -750,6 +819,7 @@ M: Andrzej Zaborowski <balrogg@gmail.com>
 M: Peter Maydell <peter.maydell@linaro.org>
 L: qemu-arm@nongnu.org
 S: Odd Fixes
+C: Low
 F: hw/arm/nseries.c
 F: hw/display/blizzard.c
 F: hw/input/lm832x.c
@@ -767,6 +837,7 @@ M: Andrzej Zaborowski <balrogg@gmail.com>
 M: Peter Maydell <peter.maydell@linaro.org>
 L: qemu-arm@nongnu.org
 S: Odd Fixes
+C: Low
 F: hw/arm/palm.c
 F: hw/input/tsc210x.c
 F: include/hw/input/tsc2xxx.h
@@ -778,6 +849,7 @@ R: Andrew Baumann <Andrew.Baumann@microsoft.com>
 R: Philippe Mathieu-Daudé <f4bug@amsat.org>
 L: qemu-arm@nongnu.org
 S: Odd Fixes
+C: Low
 F: hw/arm/raspi.c
 F: hw/arm/raspi_platform.h
 F: hw/*/bcm283*
@@ -788,6 +860,7 @@ Real View
 M: Peter Maydell <peter.maydell@linaro.org>
 L: qemu-arm@nongnu.org
 S: Maintained
+C: Low
 F: hw/arm/realview*
 F: hw/cpu/realview_mpcore.c
 F: hw/intc/realview_gic.c
@@ -799,6 +872,7 @@ M: Andrzej Zaborowski <balrogg@gmail.com>
 M: Peter Maydell <peter.maydell@linaro.org>
 L: qemu-arm@nongnu.org
 S: Odd Fixes
+C: Low
 F: hw/arm/mainstone.c
 F: hw/arm/spitz.c
 F: hw/arm/tosa.c
@@ -820,6 +894,7 @@ M: Peter Maydell <peter.maydell@linaro.org>
 R: Jean-Christophe Dubois <jcd@tribudubois.net>
 L: qemu-arm@nongnu.org
 S: Odd Fixes
+C: Low
 F: hw/arm/sabrelite.c
 F: hw/arm/fsl-imx6.c
 F: hw/misc/imx6_*.c
@@ -836,12 +911,14 @@ M: Peter Maydell <peter.maydell@linaro.org>
 R: Leif Lindholm <leif@nuviainc.com>
 L: qemu-arm@nongnu.org
 S: Maintained
+C: Low
 F: hw/arm/sbsa-ref.c
 
 Sharp SL-5500 (Collie) PDA
 M: Peter Maydell <peter.maydell@linaro.org>
 L: qemu-arm@nongnu.org
 S: Odd Fixes
+C: Low
 F: hw/arm/collie.c
 F: hw/arm/strongarm*
 
@@ -849,6 +926,7 @@ Stellaris
 M: Peter Maydell <peter.maydell@linaro.org>
 L: qemu-arm@nongnu.org
 S: Maintained
+C: Low
 F: hw/*/stellaris*
 F: include/hw/input/gamepad.h
 F: docs/system/arm/stellaris.rst
@@ -857,6 +935,7 @@ Versatile Express
 M: Peter Maydell <peter.maydell@linaro.org>
 L: qemu-arm@nongnu.org
 S: Maintained
+C: Low
 F: hw/arm/vexpress.c
 F: docs/system/arm/vexpress.rst
 
@@ -864,6 +943,7 @@ Versatile PB
 M: Peter Maydell <peter.maydell@linaro.org>
 L: qemu-arm@nongnu.org
 S: Maintained
+C: Low
 F: hw/*/versatile*
 F: include/hw/i2c/arm_sbcon_i2c.h
 F: hw/misc/arm_sysctl.c
@@ -873,6 +953,7 @@ Virt
 M: Peter Maydell <peter.maydell@linaro.org>
 L: qemu-arm@nongnu.org
 S: Maintained
+C: Low
 F: hw/arm/virt*
 F: include/hw/arm/virt.h
 
@@ -882,6 +963,7 @@ M: Alistair Francis <alistair@alistair23.me>
 M: Peter Maydell <peter.maydell@linaro.org>
 L: qemu-arm@nongnu.org
 S: Maintained
+C: Low
 F: hw/*/xilinx_*
 F: hw/*/cadence_*
 F: hw/misc/zynq*
@@ -894,6 +976,7 @@ M: Edgar E. Iglesias <edgar.iglesias@gmail.com>
 M: Peter Maydell <peter.maydell@linaro.org>
 L: qemu-arm@nongnu.org
 S: Maintained
+C: Low
 F: hw/*/xlnx*.c
 F: include/hw/*/xlnx*.h
 F: include/hw/ssi/xilinx_spips.h
@@ -904,6 +987,7 @@ ARM ACPI Subsystem
 M: Shannon Zhao <shannon.zhaosl@gmail.com>
 L: qemu-arm@nongnu.org
 S: Maintained
+C: Low
 F: hw/arm/virt-acpi-build.c
 
 STM32F205
@@ -911,6 +995,7 @@ M: Alistair Francis <alistair@alistair23.me>
 M: Peter Maydell <peter.maydell@linaro.org>
 L: qemu-arm@nongnu.org
 S: Maintained
+C: Low
 F: hw/arm/stm32f205_soc.c
 F: hw/misc/stm32f2xx_syscfg.c
 F: hw/char/stm32f2xx_usart.c
@@ -924,6 +1009,7 @@ M: Alistair Francis <alistair@alistair23.me>
 M: Peter Maydell <peter.maydell@linaro.org>
 L: qemu-arm@nongnu.org
 S: Maintained
+C: Low
 F: hw/arm/stm32f405_soc.c
 F: hw/misc/stm32f4xx_syscfg.c
 F: hw/misc/stm32f4xx_exti.c
@@ -933,6 +1019,7 @@ M: Alistair Francis <alistair@alistair23.me>
 M: Peter Maydell <peter.maydell@linaro.org>
 L: qemu-arm@nongnu.org
 S: Maintained
+C: Low
 F: hw/arm/netduino2.c
 
 Netduino Plus 2
@@ -940,6 +1027,7 @@ M: Alistair Francis <alistair@alistair23.me>
 M: Peter Maydell <peter.maydell@linaro.org>
 L: qemu-arm@nongnu.org
 S: Maintained
+C: Low
 F: hw/arm/netduinoplus2.c
 
 SmartFusion2
@@ -947,6 +1035,7 @@ M: Subbaraya Sundeep <sundeep.lkml@gmail.com>
 M: Peter Maydell <peter.maydell@linaro.org>
 L: qemu-arm@nongnu.org
 S: Maintained
+C: Low
 F: hw/arm/msf2-soc.c
 F: hw/misc/msf2-sysreg.c
 F: hw/timer/mss-timer.c
@@ -963,6 +1052,7 @@ M: Subbaraya Sundeep <sundeep.lkml@gmail.com>
 M: Peter Maydell <peter.maydell@linaro.org>
 L: qemu-arm@nongnu.org
 S: Maintained
+C: Low
 F: hw/arm/msf2-som.c
 
 ASPEED BMCs
@@ -972,6 +1062,7 @@ R: Andrew Jeffery <andrew@aj.id.au>
 R: Joel Stanley <joel@jms.id.au>
 L: qemu-arm@nongnu.org
 S: Maintained
+C: Low
 F: hw/*/*aspeed*
 F: hw/misc/pca9552.c
 F: include/hw/*/*aspeed*
@@ -984,6 +1075,7 @@ M: Joel Stanley <joel@jms.id.au>
 M: Peter Maydell <peter.maydell@linaro.org>
 L: qemu-arm@nongnu.org
 S: Maintained
+C: Low
 F: hw/*/nrf51*.c
 F: hw/*/microbit*.c
 F: include/hw/*/nrf51*.h
@@ -997,6 +1089,7 @@ AVR MCUs
 M: Michael Rolnik <mrolnik@gmail.com>
 R: Sarah Harris <S.E.Harris@kent.ac.uk>
 S: Maintained
+C: Low
 F: default-configs/avr-softmmu.mak
 F: hw/avr/
 F: include/hw/char/avr_usart.h
@@ -1010,6 +1103,7 @@ Arduino
 M: Philippe Mathieu-Daudé <f4bug@amsat.org>
 R: Sarah Harris <S.E.Harris@kent.ac.uk>
 S: Maintained
+C: Low
 F: hw/avr/arduino.c
 
 CRIS Machines
@@ -1017,6 +1111,7 @@ CRIS Machines
 Axis Dev88
 M: Edgar E. Iglesias <edgar.iglesias@gmail.com>
 S: Maintained
+C: Low
 F: hw/cris/axis_dev88.c
 F: hw/*/etraxfs_*.c
 
@@ -1026,6 +1121,7 @@ HP B160L
 M: Richard Henderson <rth@twiddle.net>
 R: Helge Deller <deller@gmx.de>
 S: Odd Fixes
+C: Low
 F: default-configs/hppa-softmmu.mak
 F: hw/hppa/
 F: pc-bios/hppa-firmware.img
@@ -1035,11 +1131,13 @@ LM32 Machines
 EVR32 and uclinux BSP
 R: Michael Walle <michael@walle.cc>
 S: Orphan
+C: Low
 F: hw/lm32/lm32_boards.c
 
 milkymist
 R: Michael Walle <michael@walle.cc>
 S: Orphan
+C: Low
 F: hw/lm32/milkymist.c
 
 M68K Machines
@@ -1047,12 +1145,14 @@ M68K Machines
 an5206
 M: Thomas Huth <huth@tuxfamily.org>
 S: Odd Fixes
+C: Low
 F: hw/m68k/an5206.c
 F: hw/m68k/mcf5206.c
 
 mcf5208
 M: Thomas Huth <huth@tuxfamily.org>
 S: Odd Fixes
+C: Low
 F: hw/m68k/mcf5208.c
 F: hw/m68k/mcf_intc.c
 F: hw/char/mcf_uart.c
@@ -1062,6 +1162,7 @@ F: include/hw/m68k/mcf*.h
 NeXTcube
 M: Thomas Huth <huth@tuxfamily.org>
 S: Odd Fixes
+C: Low
 F: hw/m68k/next-*.c
 F: hw/display/next-fb.c
 F: include/hw/m68k/next-cube.h
@@ -1069,6 +1170,7 @@ F: include/hw/m68k/next-cube.h
 q800
 M: Laurent Vivier <laurent@vivier.eu>
 S: Maintained
+C: Low
 F: hw/m68k/q800.c
 F: hw/misc/mac_via.c
 F: hw/nubus/*
@@ -1085,12 +1187,14 @@ MicroBlaze Machines
 petalogix_s3adsp1800
 M: Edgar E. Iglesias <edgar.iglesias@gmail.com>
 S: Maintained
+C: Low
 F: hw/microblaze/petalogix_s3adsp1800_mmu.c
 F: include/hw/char/xilinx_uartlite.h
 
 petalogix_ml605
 M: Edgar E. Iglesias <edgar.iglesias@gmail.com>
 S: Maintained
+C: Low
 F: hw/microblaze/petalogix_ml605_mmu.c
 
 MIPS Machines
@@ -1099,6 +1203,7 @@ Jazz
 M: Hervé Poussineau <hpoussin@reactos.org>
 R: Aleksandar Rikalo <aleksandar.rikalo@syrmia.com>
 S: Maintained
+C: Low
 F: hw/mips/jazz.c
 F: hw/display/jazz_led.c
 F: hw/dma/rc4030.c
@@ -1108,6 +1213,7 @@ M: Aleksandar Markovic <aleksandar.qemu.devel@gmail.com>
 M: Philippe Mathieu-Daudé <f4bug@amsat.org>
 R: Aurelien Jarno <aurelien@aurel32.net>
 S: Maintained
+C: Low
 F: hw/isa/piix4.c
 F: hw/acpi/piix4.c
 F: hw/mips/malta.c
@@ -1120,6 +1226,7 @@ Mipssim
 M: Aleksandar Markovic <aleksandar.qemu.devel@gmail.com>
 R: Aleksandar Rikalo <aleksandar.rikalo@syrmia.com>
 S: Odd Fixes
+C: Low
 F: hw/mips/mipssim.c
 F: hw/net/mipsnet.c
 
@@ -1128,6 +1235,7 @@ M: Aleksandar Markovic <aleksandar.qemu.devel@gmail.com>
 R: Aurelien Jarno <aurelien@aurel32.net>
 R: Aleksandar Rikalo <aleksandar.rikalo@syrmia.com>
 S: Obsolete
+C: Low
 F: hw/mips/r4k.c
 
 Fuloong 2E
@@ -1136,6 +1244,7 @@ M: Philippe Mathieu-Daudé <f4bug@amsat.org>
 M: Aleksandar Markovic <aleksandar.qemu.devel@gmail.com>
 R: Jiaxun Yang <jiaxun.yang@flygoat.com>
 S: Odd Fixes
+C: Low
 F: hw/mips/fuloong2e.c
 F: hw/isa/vt82c686.c
 F: hw/pci-host/bonito.c
@@ -1145,12 +1254,14 @@ Loongson-3 virtual platforms
 M: Huacai Chen <chenhc@lemote.com>
 R: Jiaxun Yang <jiaxun.yang@flygoat.com>
 S: Maintained
+C: Low
 F: hw/intc/loongson_liointc.c
 
 Boston
 M: Paul Burton <pburton@wavecomp.com>
 R: Aleksandar Rikalo <aleksandar.rikalo@syrmia.com>
 S: Maintained
+C: Low
 F: hw/core/loader-fit.c
 F: hw/mips/boston.c
 F: hw/pci-host/xilinx-pcie.c
@@ -1161,6 +1272,7 @@ OpenRISC Machines
 or1k-sim
 M: Jia Liu <proljc@gmail.com>
 S: Maintained
+C: Low
 F: hw/openrisc/openrisc_sim.c
 
 PowerPC Machines
@@ -1169,6 +1281,7 @@ PowerPC Machines
 M: David Gibson <david@gibson.dropbear.id.au>
 L: qemu-ppc@nongnu.org
 S: Odd Fixes
+C: Low
 F: hw/ppc/ppc405_boards.c
 
 Bamboo
@@ -1181,6 +1294,7 @@ e500
 M: David Gibson <david@gibson.dropbear.id.au>
 L: qemu-ppc@nongnu.org
 S: Odd Fixes
+C: Low
 F: hw/ppc/e500*
 F: hw/gpio/mpc8xxx.c
 F: hw/i2c/mpc_i2c.c
@@ -1194,6 +1308,7 @@ mpc8544ds
 M: David Gibson <david@gibson.dropbear.id.au>
 L: qemu-ppc@nongnu.org
 S: Odd Fixes
+C: Low
 F: hw/ppc/mpc8544ds.c
 F: hw/ppc/mpc8544_guts.c
 
@@ -1202,6 +1317,7 @@ M: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
 R: David Gibson <david@gibson.dropbear.id.au>
 L: qemu-ppc@nongnu.org
 S: Odd Fixes
+C: Low
 F: hw/ppc/mac_newworld.c
 F: hw/pci-host/uninorth.c
 F: hw/pci-bridge/dec.[hc]
@@ -1221,6 +1337,7 @@ M: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
 R: David Gibson <david@gibson.dropbear.id.au>
 L: qemu-ppc@nongnu.org
 S: Odd Fixes
+C: Low
 F: hw/ppc/mac_oldworld.c
 F: hw/pci-host/grackle.c
 F: hw/misc/macio/
@@ -1234,6 +1351,7 @@ PReP
 M: Hervé Poussineau <hpoussin@reactos.org>
 L: qemu-ppc@nongnu.org
 S: Maintained
+C: Low
 F: hw/ppc/prep.c
 F: hw/ppc/prep_systemio.c
 F: hw/ppc/rs6000_mc.c
@@ -1250,6 +1368,7 @@ sPAPR
 M: David Gibson <david@gibson.dropbear.id.au>
 L: qemu-ppc@nongnu.org
 S: Supported
+C: Low
 F: hw/*/spapr*
 F: include/hw/*/spapr*
 F: hw/*/xics*
@@ -1267,6 +1386,7 @@ M: Cédric Le Goater <clg@kaod.org>
 M: David Gibson <david@gibson.dropbear.id.au>
 L: qemu-ppc@nongnu.org
 S: Maintained
+C: Low
 F: hw/ppc/pnv*
 F: hw/intc/pnv*
 F: hw/intc/xics_pnv.c
@@ -1280,12 +1400,14 @@ virtex_ml507
 M: Edgar E. Iglesias <edgar.iglesias@gmail.com>
 L: qemu-ppc@nongnu.org
 S: Odd Fixes
+C: Low
 F: hw/ppc/virtex_ml507.c
 
 sam460ex
 M: BALATON Zoltan <balaton@eik.bme.hu>
 L: qemu-ppc@nongnu.org
 S: Maintained
+C: Low
 F: hw/ppc/sam460ex.c
 F: hw/ppc/ppc440_pcix.c
 F: hw/display/sm501*
@@ -1301,6 +1423,7 @@ OpenTitan
 M: Alistair Francis <Alistair.Francis@wdc.com>
 L: qemu-riscv@nongnu.org
 S: Supported
+C: Low
 F: hw/riscv/opentitan.c
 F: hw/char/ibex_uart.c
 F: hw/intc/ibex_plic.c
@@ -1313,6 +1436,7 @@ RX Machines
 rx-gdbsim
 M: Yoshinori Sato <ysato@users.sourceforge.jp>
 S: Maintained
+C: Low
 F: docs/system/target-rx.rst
 F: hw/rx/rx-gdbsim.c
 F: tests/acceptance/machine_rx_gdbsim.py
@@ -1323,6 +1447,7 @@ R2D
 M: Yoshinori Sato <ysato@users.sourceforge.jp>
 R: Magnus Damm <magnus.damm@gmail.com>
 S: Maintained
+C: Low
 F: hw/sh4/r2d.c
 F: hw/intc/sh_intc.c
 F: include/hw/sh4/sh_intc.h
@@ -1331,6 +1456,7 @@ Shix
 M: Yoshinori Sato <ysato@users.sourceforge.jp>
 R: Magnus Damm <magnus.damm@gmail.com>
 S: Odd Fixes
+C: Low
 F: hw/sh4/shix.c
 F: hw/intc/sh_intc.c
 F: include/hw/sh4/sh_intc.h
@@ -1340,6 +1466,7 @@ SPARC Machines
 Sun4m
 M: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
 S: Maintained
+C: Low
 F: hw/sparc/sun4m.c
 F: hw/sparc/sun4m_iommu.c
 F: hw/display/cg3.c
@@ -1355,6 +1482,7 @@ F: pc-bios/openbios-sparc32
 Sun4u
 M: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
 S: Maintained
+C: Low
 F: hw/sparc64/sun4u.c
 F: hw/sparc64/sun4u_iommu.c
 F: include/hw/sparc/sun4u_iommu.h
@@ -1368,6 +1496,7 @@ F: tests/acceptance/machine_sparc64_sun4u.py
 Sun4v
 M: Artyom Tarasenko <atar4qemu@gmail.com>
 S: Maintained
+C: Low
 F: hw/sparc64/niagara.c
 F: hw/rtc/sun4v-rtc.c
 F: include/hw/rtc/sun4v-rtc.h
@@ -1376,6 +1505,7 @@ Leon3
 M: Fabien Chouteau <chouteau@adacore.com>
 M: KONRAD Frederic <frederic.konrad@adacore.com>
 S: Maintained
+C: Low
 F: hw/sparc/leon3.c
 F: hw/*/grlib*
 F: include/hw/*/grlib*
@@ -1388,6 +1518,7 @@ M: Cornelia Huck <cohuck@redhat.com>
 M: Halil Pasic <pasic@linux.ibm.com>
 M: Christian Borntraeger <borntraeger@de.ibm.com>
 S: Supported
+C: High
 F: hw/char/sclp*.[hc]
 F: hw/char/terminal3270.c
 F: hw/s390x/
@@ -1403,6 +1534,7 @@ S390-ccw boot
 M: Christian Borntraeger <borntraeger@de.ibm.com>
 M: Thomas Huth <thuth@redhat.com>
 S: Supported
+C: High
 F: hw/s390x/ipl.*
 F: pc-bios/s390-ccw/
 F: pc-bios/s390-ccw.img
@@ -1413,6 +1545,7 @@ L: qemu-s390x@nongnu.org
 S390 PCI
 M: Matthew Rosato <mjrosato@linux.ibm.com>
 S: Supported
+C: High
 F: hw/s390x/s390-pci*
 L: qemu-s390x@nongnu.org
 
@@ -1421,6 +1554,7 @@ UniCore32 Machines
 PKUnity-3 SoC initramfs-with-busybox
 M: Guan Xuetao <gxt@mprc.pku.edu.cn>
 S: Maintained
+C: Low
 F: hw/*/puv3*
 F: hw/unicore32/
 
@@ -1430,6 +1564,7 @@ PC
 M: Michael S. Tsirkin <mst@redhat.com>
 M: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
 S: Supported
+C: High
 F: include/hw/i386/
 F: hw/i386/
 F: hw/pci-host/i440fx.c
@@ -1455,6 +1590,7 @@ PC Chipset
 M: Michael S. Tsirkin <mst@redhat.com>
 M: Paolo Bonzini <pbonzini@redhat.com>
 S: Supported
+C: High
 F: hw/char/debugcon.c
 F: hw/char/parallel*
 F: hw/char/serial*
@@ -1487,6 +1623,7 @@ microvm
 M: Sergio Lopez <slp@redhat.com>
 M: Paolo Bonzini <pbonzini@redhat.com>
 S: Maintained
+C: High
 F: docs/microvm.rst
 F: hw/i386/microvm.c
 F: include/hw/i386/microvm.h
@@ -1496,6 +1633,7 @@ Machine core
 M: Eduardo Habkost <ehabkost@redhat.com>
 M: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
 S: Supported
+C: High
 F: hw/core/cpu.c
 F: hw/core/machine-qmp-cmds.c
 F: hw/core/machine.c
@@ -1515,16 +1653,19 @@ Xtensa Machines
 sim
 M: Max Filippov <jcmvbkbc@gmail.com>
 S: Maintained
+C: Low
 F: hw/xtensa/sim.c
 
 virt
 M: Max Filippov <jcmvbkbc@gmail.com>
 S: Maintained
+C: Low
 F: hw/xtensa/virt.c
 
 XTFPGA (LX60, LX200, ML605, KC705)
 M: Max Filippov <jcmvbkbc@gmail.com>
 S: Maintained
+C: Low
 F: hw/xtensa/xtfpga.c
 F: hw/net/opencores_eth.c
 
@@ -1533,12 +1674,14 @@ Devices
 EDU
 M: Jiri Slaby <jslaby@suse.cz>
 S: Maintained
+C: Low
 F: hw/misc/edu.c
 
 IDE
 M: John Snow <jsnow@redhat.com>
 L: qemu-block@nongnu.org
 S: Supported
+C: High
 F: include/hw/ide.h
 F: include/hw/ide/
 F: hw/ide/
@@ -1554,6 +1697,7 @@ T: git https://github.com/jnsnow/qemu.git ide
 IPMI
 M: Corey Minyard <minyard@acm.org>
 S: Maintained
+C: Low
 F: include/hw/ipmi/*
 F: hw/ipmi/*
 F: hw/smbios/smbios_type_38.c
@@ -1564,6 +1708,7 @@ Floppy
 M: John Snow <jsnow@redhat.com>
 L: qemu-block@nongnu.org
 S: Supported
+C: High
 F: hw/block/fdc.c
 F: include/hw/block/fdc.h
 F: tests/qtest/fdc-test.c
@@ -1573,12 +1718,14 @@ OMAP
 M: Peter Maydell <peter.maydell@linaro.org>
 L: qemu-arm@nongnu.org
 S: Maintained
+C: Low
 F: hw/*/omap*
 F: include/hw/arm/omap.h
 
 IPack
 M: Alberto Garcia <berto@igalia.com>
 S: Odd Fixes
+C: Low
 F: hw/char/ipoctal232.c
 F: hw/ipack/
 
@@ -1586,6 +1733,7 @@ PCI
 M: Michael S. Tsirkin <mst@redhat.com>
 M: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
 S: Supported
+C: High
 F: include/hw/pci/*
 F: hw/misc/pci-testdev.c
 F: hw/pci/*
@@ -1598,6 +1746,7 @@ ACPI/SMBIOS
 M: Michael S. Tsirkin <mst@redhat.com>
 M: Igor Mammedov <imammedo@redhat.com>
 S: Supported
+C: High
 F: include/hw/acpi/*
 F: include/hw/firmware/smbios.h
 F: hw/mem/*
@@ -1614,6 +1763,7 @@ R: Dongjiu Geng <gengdongjiu@huawei.com>
 R: Xiang Zheng <zhengxiang9@huawei.com>
 L: qemu-arm@nongnu.org
 S: Maintained
+C: Low
 F: hw/acpi/ghes.c
 F: include/hw/acpi/ghes.h
 F: docs/specs/acpi_hest_ghes.rst
@@ -1622,6 +1772,7 @@ ppc4xx
 M: David Gibson <david@gibson.dropbear.id.au>
 L: qemu-ppc@nongnu.org
 S: Odd Fixes
+C: Low
 F: hw/ppc/ppc4*.c
 F: hw/i2c/ppc4xx_i2c.c
 F: include/hw/ppc/ppc4xx.h
@@ -1631,11 +1782,13 @@ Character devices
 M: Marc-André Lureau <marcandre.lureau@redhat.com>
 R: Paolo Bonzini <pbonzini@redhat.com>
 S: Odd Fixes
+C: High
 F: hw/char/
 
 Network devices
 M: Jason Wang <jasowang@redhat.com>
 S: Odd Fixes
+C: High
 F: hw/net/
 F: include/hw/net/
 F: tests/qtest/virtio-net-test.c
@@ -1646,6 +1799,7 @@ Parallel NOR Flash devices
 M: Philippe Mathieu-Daudé <philmd@redhat.com>
 T: git https://gitlab.com/philmd/qemu.git pflash-next
 S: Maintained
+C: High
 F: hw/block/pflash_cfi*.c
 F: include/hw/block/flash.h
 
@@ -1653,6 +1807,7 @@ SCSI
 M: Paolo Bonzini <pbonzini@redhat.com>
 R: Fam Zheng <fam@euphon.net>
 S: Supported
+C: High
 F: include/hw/scsi/*
 F: hw/scsi/*
 F: tests/qtest/virtio-scsi-test.c
@@ -1661,6 +1816,7 @@ T: git https://github.com/bonzini/qemu.git scsi-next
 SSI
 M: Alistair Francis <alistair@alistair23.me>
 S: Maintained
+C: Low
 F: hw/ssi/*
 F: hw/block/m25p80.c
 F: include/hw/ssi/ssi.h
@@ -1670,11 +1826,13 @@ F: tests/qtest/m25p80-test.c
 Xilinx SPI
 M: Alistair Francis <alistair@alistair23.me>
 S: Maintained
+C: Low
 F: hw/ssi/xilinx_*
 
 SD (Secure Card)
 M: Philippe Mathieu-Daudé <f4bug@amsat.org>
 S: Odd Fixes
+C: Low
 F: include/hw/sd/sd*
 F: hw/sd/core.c
 F: hw/sd/sd*
@@ -1684,6 +1842,7 @@ F: tests/qtest/sd*
 USB
 M: Gerd Hoffmann <kraxel@redhat.com>
 S: Maintained
+C: High
 F: hw/usb/*
 F: tests/qtest/usb-*-test.c
 F: docs/usb2.txt
@@ -1696,11 +1855,13 @@ USB (serial adapter)
 M: Gerd Hoffmann <kraxel@redhat.com>
 M: Samuel Thibault <samuel.thibault@ens-lyon.org>
 S: Maintained
+C: High
 F: hw/usb/dev-serial.c
 
 VFIO
 M: Alex Williamson <alex.williamson@redhat.com>
 S: Supported
+C: High
 F: hw/vfio/*
 F: include/hw/vfio/
 
@@ -1708,6 +1869,7 @@ vfio-ccw
 M: Cornelia Huck <cohuck@redhat.com>
 M: Eric Farman <farman@linux.ibm.com>
 S: Supported
+C: High
 F: hw/vfio/ccw.c
 F: hw/s390x/s390-ccw.c
 F: include/hw/s390x/s390-ccw.h
@@ -1721,6 +1883,7 @@ M: Tony Krowiak <akrowiak@linux.ibm.com>
 M: Halil Pasic <pasic@linux.ibm.com>
 M: Pierre Morel <pmorel@linux.ibm.com>
 S: Supported
+C: High
 F: hw/s390x/ap-device.c
 F: hw/s390x/ap-bridge.c
 F: include/hw/s390x/ap-device.h
@@ -1732,6 +1895,7 @@ L: qemu-s390x@nongnu.org
 vhost
 M: Michael S. Tsirkin <mst@redhat.com>
 S: Supported
+C: High
 F: hw/*/*vhost*
 F: docs/interop/vhost-user.json
 F: docs/interop/vhost-user.rst
@@ -1742,6 +1906,7 @@ F: include/sysemu/vhost-user-backend.h
 virtio
 M: Michael S. Tsirkin <mst@redhat.com>
 S: Supported
+C: High
 F: hw/*/virtio*
 F: hw/virtio/Makefile.objs
 F: hw/virtio/trace-events
@@ -1752,6 +1917,7 @@ virtio-balloon
 M: Michael S. Tsirkin <mst@redhat.com>
 M: David Hildenbrand <david@redhat.com>
 S: Maintained
+C: High
 F: hw/virtio/virtio-balloon*.c
 F: include/hw/virtio/virtio-balloon.h
 F: softmmu/balloon.c
@@ -1761,6 +1927,7 @@ virtio-9p
 M: Greg Kurz <groug@kaod.org>
 M: Christian Schoenebeck <qemu_oss@crudebyte.com>
 S: Odd Fixes
+C: Low
 F: hw/9pfs/
 X: hw/9pfs/xen-9p*
 F: fsdev/
@@ -1772,6 +1939,7 @@ virtio-blk
 M: Stefan Hajnoczi <stefanha@redhat.com>
 L: qemu-block@nongnu.org
 S: Supported
+C: High
 F: hw/block/virtio-blk.c
 F: hw/block/dataplane/*
 F: tests/qtest/virtio-blk-test.c
@@ -1781,6 +1949,7 @@ virtio-ccw
 M: Cornelia Huck <cohuck@redhat.com>
 M: Halil Pasic <pasic@linux.ibm.com>
 S: Supported
+C: High
 F: hw/s390x/virtio-ccw*.[hc]
 F: hw/s390x/vhost-vsock-ccw.c
 T: git https://github.com/cohuck/qemu.git s390-next
@@ -1791,6 +1960,7 @@ virtiofs
 M: Dr. David Alan Gilbert <dgilbert@redhat.com>
 M: Stefan Hajnoczi <stefanha@redhat.com>
 S: Supported
+C: High
 F: tools/virtiofsd/*
 F: hw/virtio/vhost-user-fs*
 F: include/hw/virtio/vhost-user-fs.h
@@ -1799,6 +1969,7 @@ F: docs/interop/virtiofsd.rst
 virtio-input
 M: Gerd Hoffmann <kraxel@redhat.com>
 S: Maintained
+C: High
 F: hw/input/vhost-user-input.c
 F: hw/input/virtio-input*.c
 F: include/hw/virtio/virtio-input.h
@@ -1807,6 +1978,7 @@ F: contrib/vhost-user-input/*
 virtio-iommu
 M: Eric Auger <eric.auger@redhat.com>
 S: Maintained
+C: High
 F: hw/virtio/virtio-iommu*.c
 F: include/hw/virtio/virtio-iommu.h
 
@@ -1814,6 +1986,7 @@ virtio-serial
 M: Laurent Vivier <lvivier@redhat.com>
 R: Amit Shah <amit@kernel.org>
 S: Supported
+C: High
 F: hw/char/virtio-serial-bus.c
 F: hw/char/virtio-console.c
 F: include/hw/virtio/virtio-serial.h
@@ -1823,6 +1996,7 @@ virtio-rng
 M: Laurent Vivier <lvivier@redhat.com>
 R: Amit Shah <amit@kernel.org>
 S: Supported
+C: High
 F: hw/virtio/virtio-rng.c
 F: include/hw/virtio/virtio-rng.h
 F: include/sysemu/rng*.h
@@ -1832,6 +2006,7 @@ F: tests/qtest/virtio-rng-test.c
 virtio-crypto
 M: Gonglei <arei.gonglei@huawei.com>
 S: Supported
+C: High
 F: hw/virtio/virtio-crypto.c
 F: hw/virtio/virtio-crypto-pci.c
 F: include/hw/virtio/virtio-crypto.h
@@ -1839,6 +2014,7 @@ F: include/hw/virtio/virtio-crypto.h
 virtio-mem
 M: David Hildenbrand <david@redhat.com>
 S: Supported
+C: High
 W: https://virtio-mem.gitlab.io/
 F: hw/virtio/virtio-mem.c
 F: hw/virtio/virtio-mem-pci.h
@@ -1849,6 +2025,7 @@ nvme
 M: Keith Busch <kbusch@kernel.org>
 L: qemu-block@nongnu.org
 S: Supported
+C: High
 F: hw/block/nvme*
 F: tests/qtest/nvme-test.c
 
@@ -1856,6 +2033,7 @@ megasas
 M: Hannes Reinecke <hare@suse.com>
 L: qemu-block@nongnu.org
 S: Supported
+C: Low
 F: hw/scsi/megasas.c
 F: hw/scsi/mfi.h
 F: tests/qtest/megasas-test.c
@@ -1863,6 +2041,7 @@ F: tests/qtest/megasas-test.c
 Network packet abstractions
 M: Dmitry Fleytman <dmitry.fleytman@gmail.com>
 S: Maintained
+C: High
 F: include/net/eth.h
 F: net/eth.c
 F: hw/net/net_rx_pkt*
@@ -1871,6 +2050,7 @@ F: hw/net/net_tx_pkt*
 Vmware
 M: Dmitry Fleytman <dmitry.fleytman@gmail.com>
 S: Maintained
+C: High
 F: hw/net/vmxnet*
 F: hw/scsi/vmw_pvscsi*
 F: tests/qtest/vmxnet3-test.c
@@ -1878,6 +2058,7 @@ F: tests/qtest/vmxnet3-test.c
 Rocker
 M: Jiri Pirko <jiri@resnulli.us>
 S: Maintained
+C: High
 F: hw/net/rocker/
 F: tests/rocker/
 F: docs/specs/rocker.txt
@@ -1885,6 +2066,7 @@ F: docs/specs/rocker.txt
 NVDIMM
 M: Xiao Guangrong <xiaoguangrong.eric@gmail.com>
 S: Maintained
+C: High
 F: hw/acpi/nvdimm.c
 F: hw/mem/nvdimm.c
 F: include/hw/mem/nvdimm.h
@@ -1893,27 +2075,32 @@ F: docs/nvdimm.txt
 e1000x
 M: Dmitry Fleytman <dmitry.fleytman@gmail.com>
 S: Maintained
+C: High
 F: hw/net/e1000x*
 
 e1000e
 M: Dmitry Fleytman <dmitry.fleytman@gmail.com>
 S: Maintained
+C: High
 F: hw/net/e1000e*
 
 eepro100
 M: Stefan Weil <sw@weilnetz.de>
 S: Maintained
+C: High
 F: hw/net/eepro100.c
 
 tulip
 M: Sven Schnelle <svens@stackframe.org>
 S: Maintained
+C: High
 F: hw/net/tulip.c
 F: hw/net/tulip.h
 
 Generic Loader
 M: Alistair Francis <alistair@alistair23.me>
 S: Maintained
+C: High
 F: hw/core/generic-loader.c
 F: include/hw/core/generic-loader.h
 F: docs/generic-loader.txt
@@ -1921,12 +2108,14 @@ F: docs/generic-loader.txt
 Intel Hexadecimal Object File Loader
 M: Su Hang <suhang16@mails.ucas.ac.cn>
 S: Maintained
+C: Low
 F: tests/qtest/hexloader-test.c
 F: tests/data/hex-loader/test.hex
 
 CHRP NVRAM
 M: Thomas Huth <thuth@redhat.com>
 S: Maintained
+C: High
 F: hw/nvram/chrp_nvram.c
 F: include/hw/nvram/chrp_nvram.h
 F: tests/qtest/prom-env-test.c
@@ -1934,6 +2123,7 @@ F: tests/qtest/prom-env-test.c
 VM Generation ID
 M: Ben Warren <ben@skyportsystems.com>
 S: Maintained
+C: Low
 F: hw/acpi/vmgenid.c
 F: include/hw/acpi/vmgenid.h
 F: docs/specs/vmgenid.txt
@@ -1944,6 +2134,7 @@ Unimplemented device
 M: Peter Maydell <peter.maydell@linaro.org>
 R: Philippe Mathieu-Daudé <f4bug@amsat.org>
 S: Maintained
+C: Low
 F: include/hw/misc/unimp.h
 F: hw/misc/unimp.c
 
@@ -1951,12 +2142,14 @@ Empty slot
 M: Artyom Tarasenko <atar4qemu@gmail.com>
 R: Philippe Mathieu-Daudé <f4bug@amsat.org>
 S: Maintained
+C: Low
 F: include/hw/misc/empty_slot.h
 F: hw/misc/empty_slot.c
 
 Standard VGA
 M: Gerd Hoffmann <kraxel@redhat.com>
 S: Maintained
+C: Low
 F: hw/display/vga*
 F: hw/display/bochs-display.c
 F: include/hw/display/vga.h
@@ -1965,12 +2158,14 @@ F: include/hw/display/bochs-vbe.h
 ramfb
 M: Gerd Hoffmann <kraxel@redhat.com>
 S: Maintained
+C: High
 F: hw/display/ramfb*.c
 F: include/hw/display/ramfb.h
 
 virtio-gpu
 M: Gerd Hoffmann <kraxel@redhat.com>
 S: Maintained
+C: High
 F: hw/display/virtio-gpu*
 F: hw/display/virtio-vga.*
 F: include/hw/virtio/virtio-gpu.h
@@ -1978,6 +2173,7 @@ F: include/hw/virtio/virtio-gpu.h
 vhost-user-blk
 M: Raphael Norwitz <raphael.norwitz@nutanix.com>
 S: Maintained
+C: High
 F: contrib/vhost-user-blk/
 F: contrib/vhost-user-scsi/
 F: hw/block/vhost-user-blk.c
@@ -1991,6 +2187,7 @@ vhost-user-gpu
 M: Marc-André Lureau <marcandre.lureau@redhat.com>
 M: Gerd Hoffmann <kraxel@redhat.com>
 S: Maintained
+C: High
 F: docs/interop/vhost-user-gpu.rst
 F: contrib/vhost-user-gpu
 F: hw/display/vhost-user-*
@@ -1998,12 +2195,14 @@ F: hw/display/vhost-user-*
 Cirrus VGA
 M: Gerd Hoffmann <kraxel@redhat.com>
 S: Odd Fixes
+C: Low
 W: https://www.kraxel.org/blog/2014/10/qemu-using-cirrus-considered-harmful/
 F: hw/display/cirrus*
 
 EDID Generator
 M: Gerd Hoffmann <kraxel@redhat.com>
 S: Maintained
+C: Low
 F: hw/display/edid*
 F: include/hw/display/edid.h
 F: qemu-edid.c
@@ -2012,6 +2211,7 @@ PIIX4 South Bridge (i82371AB)
 M: Hervé Poussineau <hpoussin@reactos.org>
 M: Philippe Mathieu-Daudé <f4bug@amsat.org>
 S: Maintained
+C: High
 F: hw/isa/piix4.c
 F: include/hw/southbridge/piix.h
 
@@ -2020,6 +2220,7 @@ M: Philippe Mathieu-Daudé <philmd@redhat.com>
 R: Laszlo Ersek <lersek@redhat.com>
 R: Gerd Hoffmann <kraxel@redhat.com>
 S: Supported
+C: High
 F: docs/specs/fw_cfg.txt
 F: hw/nvram/fw_cfg.c
 F: stubs/fw_cfg.c
@@ -2034,6 +2235,7 @@ M: David Gibson <david@gibson.dropbear.id.au>
 M: Cédric Le Goater <clg@kaod.org>
 L: qemu-ppc@nongnu.org
 S: Supported
+C: High
 F: hw/*/*xive*
 F: include/hw/*/*xive*
 F: docs/*/*xive*
@@ -2042,6 +2244,7 @@ Renesas peripherals
 M: Yoshinori Sato <ysato@users.sourceforge.jp>
 R: Magnus Damm <magnus.damm@gmail.com>
 S: Maintained
+C: Low
 F: hw/char/renesas_sci.c
 F: hw/char/sh_serial.c
 F: hw/timer/renesas_*.c
@@ -2053,6 +2256,7 @@ F: include/hw/timer/renesas_*.h
 Renesas RX peripherals
 M: Yoshinori Sato <ysato@users.sourceforge.jp>
 S: Maintained
+C: Low
 F: hw/intc/rx_icu.c
 F: hw/rx/
 F: include/hw/intc/rx_icu.h
@@ -2063,6 +2267,7 @@ Subsystems
 Audio
 M: Gerd Hoffmann <kraxel@redhat.com>
 S: Maintained
+C: High
 F: audio/
 F: hw/audio/
 F: include/hw/audio/
@@ -2075,6 +2280,7 @@ M: Kevin Wolf <kwolf@redhat.com>
 M: Max Reitz <mreitz@redhat.com>
 L: qemu-block@nongnu.org
 S: Supported
+C: High
 F: block*
 F: block/
 F: hw/block/
@@ -2093,6 +2299,7 @@ M: Stefan Hajnoczi <stefanha@redhat.com>
 M: Fam Zheng <fam@euphon.net>
 L: qemu-block@nongnu.org
 S: Supported
+C: High
 F: util/async.c
 F: util/aio-*.c
 F: util/aio-*.h
@@ -2109,6 +2316,7 @@ M: Paolo Bonzini <pbonzini@redhat.com>
 R: Fam Zheng <fam@euphon.net>
 L: qemu-block@nongnu.org
 S: Supported
+C: High
 F: include/scsi/*
 F: scsi/*
 
@@ -2116,6 +2324,7 @@ Block Jobs
 M: John Snow <jsnow@redhat.com>
 L: qemu-block@nongnu.org
 S: Supported
+C: High
 F: blockjob.c
 F: include/block/blockjob.h
 F: job.c
@@ -2131,6 +2340,7 @@ T: git https://github.com/jnsnow/qemu.git jobs
 Block QAPI, monitor, command line
 M: Markus Armbruster <armbru@redhat.com>
 S: Supported
+C: High
 F: blockdev.c
 F: blockdev-hmp-cmds.c
 F: block/qapi.c
@@ -2144,6 +2354,7 @@ M: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
 R: John Snow <jsnow@redhat.com>
 L: qemu-block@nongnu.org
 S: Supported
+C: High
 F: include/qemu/hbitmap.h
 F: include/block/dirty-bitmap.h
 F: block/monitor/bitmap-qmp-cmds.c
@@ -2159,6 +2370,7 @@ Character device backends
 M: Marc-André Lureau <marcandre.lureau@redhat.com>
 R: Paolo Bonzini <pbonzini@redhat.com>
 S: Maintained
+C: High
 F: chardev/
 F: include/chardev/
 F: qapi/char.json
@@ -2166,11 +2378,13 @@ F: qapi/char.json
 Character Devices (Braille)
 M: Samuel Thibault <samuel.thibault@ens-lyon.org>
 S: Maintained
+C: High
 F: chardev/baum.c
 
 Command line option argument parsing
 M: Markus Armbruster <armbru@redhat.com>
 S: Supported
+C: High
 F: include/qemu/option.h
 F: tests/test-keyval.c
 F: tests/test-qemu-opts.c
@@ -2180,22 +2394,26 @@ F: util/qemu-option.c
 Coverity model
 M: Markus Armbruster <armbru@redhat.com>
 S: Supported
+C: Low
 F: scripts/coverity-model.c
 
 Coverity Scan integration
 M: Peter Maydell <peter.maydell@linaro.org>
 S: Maintained
+C: Low
 F: scripts/coverity-scan/
 
 Device Tree
 M: Alistair Francis <alistair.francis@wdc.com>
 R: David Gibson <david@gibson.dropbear.id.au>
 S: Maintained
+C: Low
 F: device_tree.c
 F: include/sysemu/device_tree.h
 
 Dump
 S: Supported
+C: Low
 M: Marc-André Lureau <marcandre.lureau@redhat.com>
 F: dump/
 F: hw/misc/vmcoreinfo.c
@@ -2210,6 +2428,7 @@ F: stubs/dump.c
 Error reporting
 M: Markus Armbruster <armbru@redhat.com>
 S: Supported
+C: High
 F: include/qapi/error.h
 F: include/qemu/error-report.h
 F: qapi/error.json
@@ -2226,12 +2445,14 @@ GDB stub
 M: Alex Bennée <alex.bennee@linaro.org>
 R: Philippe Mathieu-Daudé <philmd@redhat.com>
 S: Maintained
+C: Low
 F: gdbstub*
 F: gdb-xml/
 
 Memory API
 M: Paolo Bonzini <pbonzini@redhat.com>
 S: Supported
+C: High
 F: include/exec/ioport.h
 F: include/exec/memop.h
 F: include/exec/memory.h
@@ -2246,6 +2467,7 @@ F: scripts/coccinelle/memory-region-housekeeping.cocci
 SPICE
 M: Gerd Hoffmann <kraxel@redhat.com>
 S: Supported
+C: High
 F: include/ui/qemu-spice.h
 F: include/ui/spice-display.h
 F: ui/spice-*.c
@@ -2257,6 +2479,7 @@ F: docs/spice-port-fqdn.txt
 Graphics
 M: Gerd Hoffmann <kraxel@redhat.com>
 S: Odd Fixes
+C: Low
 F: ui/
 F: include/ui/
 F: qapi/ui.json
@@ -2265,11 +2488,13 @@ F: util/drm.c
 Cocoa graphics
 M: Peter Maydell <peter.maydell@linaro.org>
 S: Odd Fixes
+C: Low
 F: ui/cocoa.m
 
 Main loop
 M: Paolo Bonzini <pbonzini@redhat.com>
 S: Maintained
+C: High
 F: include/qemu/main-loop.h
 F: include/sysemu/runstate.h
 F: util/main-loop.c
@@ -2283,6 +2508,7 @@ F: qapi/run-state.json
 Human Monitor (HMP)
 M: Dr. David Alan Gilbert <dgilbert@redhat.com>
 S: Maintained
+C: Low
 F: monitor/monitor-internal.h
 F: monitor/misc.c
 F: monitor/monitor.c
@@ -2297,6 +2523,7 @@ F: util/qemu-print.c
 Network device backends
 M: Jason Wang <jasowang@redhat.com>
 S: Maintained
+C: High
 F: net/
 F: include/net/
 F: qemu-bridge-helper.c
@@ -2309,12 +2536,14 @@ M: Giuseppe Lettieri <g.lettieri@iet.unipi.it>
 M: Vincenzo Maffione <v.maffione@gmail.com>
 W: http://info.iet.unipi.it/~luigi/netmap/
 S: Maintained
+C: High
 F: net/netmap.c
 
 Host Memory Backends
 M: Eduardo Habkost <ehabkost@redhat.com>
 M: Igor Mammedov <imammedo@redhat.com>
 S: Maintained
+C: High
 F: backends/hostmem*.c
 F: include/sysemu/hostmem.h
 T: git https://github.com/ehabkost/qemu.git machine-next
@@ -2322,6 +2551,7 @@ T: git https://github.com/ehabkost/qemu.git machine-next
 Cryptodev Backends
 M: Gonglei <arei.gonglei@huawei.com>
 S: Maintained
+C: High
 F: include/sysemu/cryptodev*.h
 F: backends/cryptodev*.c
 
@@ -2329,6 +2559,7 @@ Python scripts
 M: Eduardo Habkost <ehabkost@redhat.com>
 M: Cleber Rosa <crosa@redhat.com>
 S: Odd fixes
+C: Low
 F: python/qemu/*py
 F: scripts/*.py
 F: tests/*.py
@@ -2336,12 +2567,14 @@ F: tests/*.py
 Benchmark util
 M: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
 S: Maintained
+C: Low
 F: scripts/simplebench/
 
 QAPI
 M: Markus Armbruster <armbru@redhat.com>
 M: Michael Roth <mdroth@linux.vnet.ibm.com>
 S: Supported
+C: High
 F: qapi/
 X: qapi/*.json
 F: include/qapi/
@@ -2361,12 +2594,14 @@ QAPI Schema
 M: Eric Blake <eblake@redhat.com>
 M: Markus Armbruster <armbru@redhat.com>
 S: Supported
+C: Low
 F: qapi/*.json
 T: git https://repo.or.cz/qemu/armbru.git qapi-next
 
 QObject
 M: Markus Armbruster <armbru@redhat.com>
 S: Supported
+C: Low
 F: qobject/
 F: include/qapi/qmp/
 X: include/qapi/qmp/dispatch.h
@@ -2385,6 +2620,7 @@ T: git https://repo.or.cz/qemu/armbru.git qapi-next
 QEMU Guest Agent
 M: Michael Roth <mdroth@linux.vnet.ibm.com>
 S: Maintained
+C: Low
 F: qga/
 F: docs/interop/qemu-ga.rst
 F: scripts/qemu-guest-agent/
@@ -2397,6 +2633,7 @@ M: Paolo Bonzini <pbonzini@redhat.com>
 R: Daniel P. Berrange <berrange@redhat.com>
 R: Eduardo Habkost <ehabkost@redhat.com>
 S: Supported
+C: High
 F: docs/qdev-device-use.txt
 F: hw/core/qdev*
 F: hw/core/bus.c
@@ -2415,6 +2652,7 @@ F: tests/test-qdev-global-props.c
 QMP
 M: Markus Armbruster <armbru@redhat.com>
 S: Supported
+C: Low
 F: monitor/monitor-internal.h
 F: monitor/qmp*
 F: monitor/misc.c
@@ -2432,6 +2670,7 @@ M: Thomas Huth <thuth@redhat.com>
 M: Laurent Vivier <lvivier@redhat.com>
 R: Paolo Bonzini <pbonzini@redhat.com>
 S: Maintained
+C: Low
 F: softmmu/qtest.c
 F: accel/qtest.c
 F: tests/qtest/
@@ -2443,12 +2682,14 @@ R: Paolo Bonzini <pbonzini@redhat.com>
 R: Bandan Das <bsd@redhat.com>
 R: Stefan Hajnoczi <stefanha@redhat.com>
 S: Maintained
+C: Low
 F: tests/qtest/fuzz/
 F: scripts/oss-fuzz/
 
 Register API
 M: Alistair Francis <alistair@alistair23.me>
 S: Maintained
+C: High
 F: hw/core/register.c
 F: include/hw/register.h
 F: include/hw/registerfields.h
@@ -2456,6 +2697,7 @@ F: include/hw/registerfields.h
 SLIRP
 M: Samuel Thibault <samuel.thibault@ens-lyon.org>
 S: Maintained
+C: Low
 F: slirp/
 F: net/slirp.c
 F: include/net/slirp.h
@@ -2464,17 +2706,20 @@ T: git https://people.debian.org/~sthibault/qemu.git slirp
 Streams
 M: Edgar E. Iglesias <edgar.iglesias@gmail.com>
 S: Maintained
+C: Low
 F: hw/core/stream.c
 F: include/hw/stream.h
 
 Stubs
 M: Paolo Bonzini <pbonzini@redhat.com>
 S: Maintained
+C: Low
 F: stubs/
 
 Tracing
 M: Stefan Hajnoczi <stefanha@redhat.com>
 S: Maintained
+C: Low
 F: trace/
 F: trace-events
 F: docs/qemu-option-trace.rst.inc
@@ -2488,6 +2733,7 @@ T: git https://github.com/stefanha/qemu.git tracing
 TPM
 M: Stefan Berger <stefanb@linux.ibm.com>
 S: Maintained
+C: Low
 F: tpm.c
 F: stubs/tpm.c
 F: hw/tpm/*
@@ -2500,12 +2746,14 @@ T: git https://github.com/stefanberger/qemu-tpm.git tpm-next
 
 Checkpatch
 S: Odd Fixes
+C: Low
 F: scripts/checkpatch.pl
 
 Migration
 M: Juan Quintela <quintela@redhat.com>
 M: Dr. David Alan Gilbert <dgilbert@redhat.com>
 S: Maintained
+C: High
 F: hw/core/vmstate-if.c
 F: include/hw/vmstate-if.h
 F: include/migration/
@@ -2519,6 +2767,7 @@ F: qapi/migration.json
 D-Bus
 M: Marc-André Lureau <marcandre.lureau@redhat.com>
 S: Maintained
+C: High
 F: backends/dbus-vmstate.c
 F: tests/dbus-vmstate*
 F: util/dbus.c
@@ -2529,12 +2778,14 @@ F: docs/interop/dbus-vmstate.rst
 Seccomp
 M: Eduardo Otubo <otubo@redhat.com>
 S: Supported
+C: High
 F: qemu-seccomp.c
 F: include/sysemu/seccomp.h
 
 Cryptography
 M: Daniel P. Berrange <berrange@redhat.com>
 S: Maintained
+C: High
 F: crypto/
 F: include/crypto/
 F: tests/test-crypto-*
@@ -2547,6 +2798,7 @@ Coroutines
 M: Stefan Hajnoczi <stefanha@redhat.com>
 M: Kevin Wolf <kwolf@redhat.com>
 S: Maintained
+C: High
 F: util/*coroutine*
 F: include/qemu/coroutine*
 F: tests/test-coroutine.c
@@ -2554,12 +2806,14 @@ F: tests/test-coroutine.c
 Buffers
 M: Daniel P. Berrange <berrange@redhat.com>
 S: Odd fixes
+C: Low
 F: util/buffer.c
 F: include/qemu/buffer.h
 
 I/O Channels
 M: Daniel P. Berrange <berrange@redhat.com>
 S: Maintained
+C: High
 F: io/
 F: include/io/
 F: tests/test-io-*
@@ -2567,6 +2821,7 @@ F: tests/test-io-*
 User authorization
 M: Daniel P. Berrange <berrange@redhat.com>
 S: Maintained
+C: High
 F: authz/
 F: qapi/authz.json
 F: include/authz/
@@ -2576,6 +2831,7 @@ Sockets
 M: Daniel P. Berrange <berrange@redhat.com>
 M: Gerd Hoffmann <kraxel@redhat.com>
 S: Maintained
+C: High
 F: include/qemu/sockets.h
 F: util/qemu-sockets.c
 F: qapi/sockets.json
@@ -2583,6 +2839,7 @@ F: qapi/sockets.json
 File monitor
 M: Daniel P. Berrange <berrange@redhat.com>
 S: Odd fixes
+C: Low
 F: util/filemonitor*.c
 F: include/qemu/filemonitor.h
 F: tests/test-util-filemonitor.c
@@ -2590,6 +2847,7 @@ F: tests/test-util-filemonitor.c
 Throttling infrastructure
 M: Alberto Garcia <berto@igalia.com>
 S: Supported
+C: High
 F: block/throttle-groups.c
 F: include/block/throttle-groups.h
 F: include/qemu/throttle*.h
@@ -2601,6 +2859,7 @@ L: qemu-block@nongnu.org
 UUID
 M: Fam Zheng <fam@euphon.net>
 S: Supported
+C: Low
 F: util/uuid.c
 F: include/qemu/uuid.h
 F: tests/test-uuid.c
@@ -2608,6 +2867,7 @@ F: tests/test-uuid.c
 COLO Framework
 M: zhanghailiang <zhang.zhanghailiang@huawei.com>
 S: Maintained
+C: High
 F: migration/colo*
 F: include/migration/colo.h
 F: include/migration/failover.h
@@ -2617,6 +2877,7 @@ COLO Proxy
 M: Zhang Chen <chen.zhang@intel.com>
 M: Li Zhijian <lizhijian@cn.fujitsu.com>
 S: Supported
+C: High
 F: docs/colo-proxy.txt
 F: net/colo*
 F: net/filter-rewriter.c
@@ -2627,6 +2888,7 @@ M: Pavel Dovgalyuk <pavel.dovgaluk@ispras.ru>
 R: Paolo Bonzini <pbonzini@redhat.com>
 W: https://wiki.qemu.org/Features/record-replay
 S: Supported
+C: High
 F: replay/*
 F: block/blkreplay.c
 F: net/filter-replay.c
@@ -2638,17 +2900,20 @@ F: tests/acceptance/replay_kernel.py
 IOVA Tree
 M: Peter Xu <peterx@redhat.com>
 S: Maintained
+C: Low
 F: include/qemu/iova-tree.h
 F: util/iova-tree.c
 
 elf2dmp
 M: Viktor Prutyanov <viktor.prutyanov@phystech.edu>
 S: Maintained
+C: Low
 F: contrib/elf2dmp/
 
 I2C and SMBus
 M: Corey Minyard <cminyard@mvista.com>
 S: Maintained
+C: High
 F: hw/i2c/core.c
 F: hw/i2c/smbus_slave.c
 F: hw/i2c/smbus_master.c
@@ -2662,6 +2927,7 @@ EDK2 Firmware
 M: Laszlo Ersek <lersek@redhat.com>
 M: Philippe Mathieu-Daudé <philmd@redhat.com>
 S: Supported
+C: High
 F: pc-bios/descriptors/??-edk2-*.json
 F: pc-bios/edk2-*
 F: roms/Makefile.edk2
@@ -2677,6 +2943,7 @@ M: Michael S. Tsirkin <mst@redhat.com>
 M: Peter Xu <peterx@redhat.com>
 R: Jason Wang <jasowang@redhat.com>
 S: Supported
+C: High
 F: hw/i386/intel_iommu.c
 F: hw/i386/intel_iommu_internal.h
 F: include/hw/i386/intel_iommu.h
@@ -2686,17 +2953,20 @@ Usermode Emulation
 Overall usermode emulation
 M: Riku Voipio <riku.voipio@iki.fi>
 S: Maintained
+C: Low
 F: thunk.c
 F: accel/tcg/user-exec*.c
 
 BSD user
 S: Orphan
+C: Low
 F: bsd-user/
 F: default-configs/*-bsd-user.mak
 
 Linux user
 M: Laurent Vivier <laurent@vivier.eu>
 S: Maintained
+C: Low
 F: linux-user/
 F: default-configs/*-linux-user.mak
 F: scripts/qemu-binfmt-conf.sh
@@ -2709,12 +2979,14 @@ Tiny Code Generator (TCG)
 Common TCG code
 M: Richard Henderson <rth@twiddle.net>
 S: Maintained
+C: Low
 F: tcg/
 F: include/tcg/
 
 TCG Plugins
 M: Alex Bennée <alex.bennee@linaro.org>
 S: Maintained
+C: Low
 F: docs/devel/tcg-plugins.rst
 F: plugins/
 F: tests/plugin
@@ -2722,6 +2994,7 @@ F: tests/plugin
 AArch64 TCG target
 M: Richard Henderson <richard.henderson@linaro.org>
 S: Maintained
+C: Low
 L: qemu-arm@nongnu.org
 F: tcg/aarch64/
 F: disas/arm-a64.cc
@@ -2730,6 +3003,7 @@ F: disas/libvixl/
 ARM TCG target
 M: Andrzej Zaborowski <balrogg@gmail.com>
 S: Maintained
+C: Low
 L: qemu-arm@nongnu.org
 F: tcg/arm/
 F: disas/arm.c
@@ -2737,6 +3011,7 @@ F: disas/arm.c
 i386 TCG target
 M: Richard Henderson <rth@twiddle.net>
 S: Maintained
+C: Low
 F: tcg/i386/
 F: disas/i386.c
 
@@ -2745,11 +3020,13 @@ M: Aleksandar Markovic <aleksandar.qemu.devel@gmail.com>
 R: Aurelien Jarno <aurelien@aurel32.net>
 R: Aleksandar Rikalo <aleksandar.rikalo@syrmia.com>
 S: Maintained
+C: Low
 F: tcg/mips/
 
 PPC TCG target
 M: Richard Henderson <rth@twiddle.net>
 S: Odd Fixes
+C: Low
 F: tcg/ppc/
 F: disas/ppc.c
 
@@ -2758,24 +3035,28 @@ M: Palmer Dabbelt <palmer@dabbelt.com>
 M: Alistair Francis <Alistair.Francis@wdc.com>
 L: qemu-riscv@nongnu.org
 S: Maintained
+C: Low
 F: tcg/riscv/
 F: disas/riscv.c
 
 S390 TCG target
 M: Richard Henderson <rth@twiddle.net>
 S: Maintained
+C: Low
 F: tcg/s390/
 F: disas/s390.c
 L: qemu-s390x@nongnu.org
 
 SPARC TCG target
 S: Odd Fixes
+C: Low
 F: tcg/sparc/
 F: disas/sparc.c
 
 TCI TCG target
 M: Stefan Weil <sw@weilnetz.de>
 S: Maintained
+C: Low
 F: tcg/tci/
 F: tcg/tci.c
 F: disas/tci.c
@@ -2786,12 +3067,14 @@ VMDK
 M: Fam Zheng <fam@euphon.net>
 L: qemu-block@nongnu.org
 S: Supported
+C: High
 F: block/vmdk.c
 
 RBD
 M: Jason Dillaman <dillaman@redhat.com>
 L: qemu-block@nongnu.org
 S: Supported
+C: High
 F: block/rbd.c
 
 Sheepdog
@@ -2799,18 +3082,21 @@ M: Liu Yuan <namei.unix@gmail.com>
 L: qemu-block@nongnu.org
 L: sheepdog@lists.wpkg.org
 S: Odd Fixes
+C: Low
 F: block/sheepdog.c
 
 VHDX
 M: Jeff Cody <codyprime@gmail.com>
 L: qemu-block@nongnu.org
 S: Supported
+C: High
 F: block/vhdx*
 
 VDI
 M: Stefan Weil <sw@weilnetz.de>
 L: qemu-block@nongnu.org
 S: Maintained
+C: High
 F: block/vdi.c
 
 iSCSI
@@ -2819,6 +3105,7 @@ M: Paolo Bonzini <pbonzini@redhat.com>
 M: Peter Lieven <pl@kamp.de>
 L: qemu-block@nongnu.org
 S: Odd Fixes
+C: Low
 F: block/iscsi.c
 F: block/iscsi-opts.c
 
@@ -2826,6 +3113,7 @@ Network Block Device (NBD)
 M: Eric Blake <eblake@redhat.com>
 L: qemu-block@nongnu.org
 S: Maintained
+C: High
 F: block/nbd*
 F: nbd/
 F: include/block/nbd*
@@ -2839,45 +3127,53 @@ NFS
 M: Peter Lieven <pl@kamp.de>
 L: qemu-block@nongnu.org
 S: Maintained
+C: High
 F: block/nfs.c
 
 SSH
 M: Richard W.M. Jones <rjones@redhat.com>
 L: qemu-block@nongnu.org
 S: Supported
+C: High
 F: block/ssh.c
 
 CURL
 L: qemu-block@nongnu.org
 S: Odd Fixes
+C: Low
 F: block/curl.c
 
 GLUSTER
 L: qemu-block@nongnu.org
 L: integration@gluster.org
 S: Odd Fixes
+C: Low
 F: block/gluster.c
 
 Null Block Driver
 M: Fam Zheng <fam@euphon.net>
 L: qemu-block@nongnu.org
 S: Supported
+C: Low
 F: block/null.c
 
 NVMe Block Driver
 M: Fam Zheng <fam@euphon.net>
 L: qemu-block@nongnu.org
 S: Supported
+C: Low
 F: block/nvme*
 
 Bootdevice
 M: Gonglei <arei.gonglei@huawei.com>
 S: Maintained
+C: Low
 F: bootdevice.c
 
 Quorum
 M: Alberto Garcia <berto@igalia.com>
 S: Supported
+C: High
 F: block/quorum.c
 L: qemu-block@nongnu.org
 
@@ -2885,30 +3181,35 @@ blklogwrites
 M: Ari Sundholm <ari@tuxera.com>
 L: qemu-block@nongnu.org
 S: Supported
+C: High
 F: block/blklogwrites.c
 
 blkverify
 M: Stefan Hajnoczi <stefanha@redhat.com>
 L: qemu-block@nongnu.org
 S: Supported
+C: High
 F: block/blkverify.c
 
 bochs
 M: Stefan Hajnoczi <stefanha@redhat.com>
 L: qemu-block@nongnu.org
 S: Supported
+C: Low
 F: block/bochs.c
 
 cloop
 M: Stefan Hajnoczi <stefanha@redhat.com>
 L: qemu-block@nongnu.org
 S: Supported
+C: Low
 F: block/cloop.c
 
 dmg
 M: Stefan Hajnoczi <stefanha@redhat.com>
 L: qemu-block@nongnu.org
 S: Supported
+C: High
 F: block/dmg.c
 
 parallels
@@ -2916,6 +3217,7 @@ M: Stefan Hajnoczi <stefanha@redhat.com>
 M: Denis V. Lunev <den@openvz.org>
 L: qemu-block@nongnu.org
 S: Supported
+C: High
 F: block/parallels.c
 F: docs/interop/parallels.txt
 
@@ -2923,12 +3225,14 @@ qed
 M: Stefan Hajnoczi <stefanha@redhat.com>
 L: qemu-block@nongnu.org
 S: Supported
+C: High
 F: block/qed.c
 
 raw
 M: Kevin Wolf <kwolf@redhat.com>
 L: qemu-block@nongnu.org
 S: Supported
+C: High
 F: block/linux-aio.c
 F: include/block/raw-aio.h
 F: block/raw-format.c
@@ -2942,6 +3246,7 @@ M: Julia Suvorova <jusual@redhat.com>
 M: Stefan Hajnoczi <stefanha@redhat.com>
 L: qemu-block@nongnu.org
 S: Maintained
+C: High
 F: block/io_uring.c
 F: stubs/io_uring.c
 
@@ -2950,6 +3255,7 @@ M: Kevin Wolf <kwolf@redhat.com>
 M: Max Reitz <mreitz@redhat.com>
 L: qemu-block@nongnu.org
 S: Supported
+C: High
 F: block/qcow2*
 F: docs/interop/qcow2.txt
 
@@ -2957,6 +3263,7 @@ qcow
 M: Kevin Wolf <kwolf@redhat.com>
 L: qemu-block@nongnu.org
 S: Supported
+C: High
 F: block/qcow.c
 
 blkdebug
@@ -2964,30 +3271,35 @@ M: Kevin Wolf <kwolf@redhat.com>
 M: Max Reitz <mreitz@redhat.com>
 L: qemu-block@nongnu.org
 S: Supported
+C: High
 F: block/blkdebug.c
 
 vpc
 M: Kevin Wolf <kwolf@redhat.com>
 L: qemu-block@nongnu.org
 S: Supported
+C: High
 F: block/vpc.c
 
 vvfat
 M: Kevin Wolf <kwolf@redhat.com>
 L: qemu-block@nongnu.org
 S: Supported
+C: Low
 F: block/vvfat.c
 
 Image format fuzzer
 M: Stefan Hajnoczi <stefanha@redhat.com>
 L: qemu-block@nongnu.org
 S: Supported
+C: Low
 F: tests/image-fuzzer/
 
 Replication
 M: Wen Congyang <wencongyang2@huawei.com>
 M: Xie Changlong <xiechanglong.d@gmail.com>
 S: Supported
+C: Low
 F: replication*
 F: block/replication.c
 F: tests/test-replication.c
@@ -2997,6 +3309,7 @@ PVRDMA
 M: Yuval Shaia <yuval.shaia.ml@gmail.com>
 M: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
 S: Maintained
+C: High
 F: hw/rdma/*
 F: hw/rdma/vmw/*
 F: docs/pvrdma.txt
@@ -3006,6 +3319,7 @@ F: qapi/rdma.json
 Semihosting
 M: Alex Bennée <alex.bennee@linaro.org>
 S: Maintained
+C: Low
 F: hw/semihosting/
 F: include/hw/semihosting/
 
@@ -3016,6 +3330,7 @@ M: Alex Bennée <alex.bennee@linaro.org>
 M: Fam Zheng <fam@euphon.net>
 R: Philippe Mathieu-Daudé <philmd@redhat.com>
 S: Maintained
+C: Low
 F: .github/lockdown.yml
 F: .travis.yml
 F: scripts/travis/
@@ -3031,6 +3346,7 @@ FreeBSD Hosted Continuous Integration
 M: Ed Maste <emaste@freebsd.org>
 M: Li-Wen Hsu <lwhsu@freebsd.org>
 S: Maintained
+C: Low
 F: .cirrus.yml
 W: https://cirrus-ci.com/github/qemu/qemu
 
@@ -3040,12 +3356,14 @@ M: Philippe Mathieu-Daudé <philmd@redhat.com>
 M: Alex Bennée <alex.bennee@linaro.org>
 R: Wainer dos Santos Moschetta <wainersm@redhat.com>
 S: Maintained
+C: Low
 F: .gitlab-ci.yml
 
 Guest Test Compilation Support
 M: Alex Bennée <alex.bennee@linaro.org>
 R: Philippe Mathieu-Daudé <f4bug@amsat.org>
 S: Maintained
+C: Low
 F: tests/tcg/Makefile
 F: tests/tcg/Makefile.include
 
@@ -3055,6 +3373,7 @@ R: Cleber Rosa <crosa@redhat.com>
 R: Philippe Mathieu-Daudé <philmd@redhat.com>
 R: Wainer dos Santos Moschetta <wainersm@redhat.com>
 S: Odd Fixes
+C: Low
 F: tests/acceptance/
 
 Documentation
@@ -3062,11 +3381,13 @@ Documentation
 Build system architecture
 M: Daniel P. Berrange <berrange@redhat.com>
 S: Odd Fixes
+C: Low
 F: docs/devel/build-system.txt
 
 GIT Data Mining Config
 M: Alex Bennée <alex.bennee@linaro.org>
 S: Odd Fixes
+C: Low
 F: gitdm.config
 F: contrib/gitdm/*
 
@@ -3079,6 +3400,7 @@ Build System
 GIT submodules
 M: Daniel P. Berrange <berrange@redhat.com>
 S: Odd Fixes
+C: Low
 F: scripts/git-submodule.sh
 
 UI translations
@@ -3088,6 +3410,7 @@ F: po/*.po
 Sphinx documentation configuration and build machinery
 M: Peter Maydell <peter.maydell@linaro.org>
 S: Maintained
+C: Low
 F: docs/conf.py
 F: docs/*/conf.py
 
@@ -3096,4 +3419,5 @@ Miscellaneous
 Performance Tools and Tests
 M: Ahmed Karaman <ahmedkhaledkaraman@gmail.com>
 S: Maintained
+C: Low
 F: scripts/performance/
-- 
2.26.2



^ permalink raw reply related	[flat|nested] 28+ messages in thread
* Re: [PATCH 1/1] MAINTAINERS: introduce cve or security quotient field
  2020-07-14  8:36 ` [PATCH 1/1] MAINTAINERS: introduce cve or " P J P
@ 2020-07-14  9:42   ` Peter Maydell
  2020-07-14  9:52     ` Daniel P. Berrangé
  2020-07-14 10:18   ` Philippe Mathieu-Daudé
                     ` (2 subsequent siblings)
  3 siblings, 1 reply; 28+ messages in thread
From: Peter Maydell @ 2020-07-14  9:42 UTC (permalink / raw)
  To: P J P
  Cc: Kevin Wolf, Stefano Stabellini, Daniel P . Berrange,
	Prasad J Pandit, Michael S . Tsirkin, Christian Schoenebeck,
	Michael Roth, QEMU Developers, Greg Kurz, Stefan Hajnoczi,
	Paolo Bonzini

On Tue, 14 Jul 2020 at 09:40, P J P <ppandit@redhat.com> wrote:
>
> From: Prasad J Pandit <pjp@fedoraproject.org>
>
> QEMU supports numerous virtualisation and emulation use cases.
> It also offers many features to support guest's function(s).
>
> All of these use cases and features are not always security relevant.
> Because some maybe used in trusted environments only. Some may still
> be in experimental stage. While other could be very old and not
> used or maintained actively.
>
> For security bug analysis we generally consider use cases wherein
> QEMU is used in conjunction with the KVM hypervisor, which enables
> guest to use hardware processor's virtualisation features.
>
> The CVE (or Security or Trust) Quotient field tries to capture this
> sensitivity pertaining to a feature or section of the code.
>
> It indicates whether a potential issue should be treated as a security
> one OR it could be fixed as a regular non-security bug.

How does this interact with the way we already document our
level of security support in docs/system/security.rst ?

> +       C: CVE/Security/Trust Quotient
> +          H:High - Feature (or code) is meant to be safe and used by untrusted
> +                   guests. So any potential security issue must be processed with
> +                   due care and be considered as a CVE issue.
> +          L:Low  - Feature (or code) is not meant to be safe OR is experimental
> +                   OR is used in trusted environments only OR is not well
> +                   maintained. So any potential security issue can be processed
> +                   and fixed as regular non-security bug. No need for a CVE.

The difficulty with this is that MAINTAINERS is not set up
with a split between "security issues" and "non-security
issues". For instance this stanza:

> @@ -149,6 +161,7 @@ ARM TCG CPUs
>  M: Peter Maydell <peter.maydell@linaro.org>
>  L: qemu-arm@nongnu.org
>  S: Maintained
> +C: Low
>  F: target/arm/
>  F: tests/tcg/arm/
>  F: tests/tcg/aarch64/

you have marked "Low", but the files it covers include
both ones used by TCG (not security-critical) and ones
used by KVM (security-critical).

Also, MAINTAINERS is not user-facing. If we want to say
that vvfat or 9pfs are not suitable for use on a security
boundary and that we do not consider bugs in them to
be security issues, we should do that in the user-facing
documentation.

Broadly speaking, it feels like you're trying to come up
with an automatic way to say "does this patch touch a
security-relevant part of the code", and I'm not sure
that that's possible.

>  GIT Data Mining Config
>  M: Alex Bennée <alex.bennee@linaro.org>

Something in your patch workflow is mangling UTF-8 characters,
incidentally.

thanks
-- PMM


^ permalink raw reply	[flat|nested] 28+ messages in thread
* Re: [PATCH 0/1] MAINTAINERS: add security quotient field
  2020-07-14  8:36 [PATCH 0/1] MAINTAINERS: add security quotient field P J P
  2020-07-14  8:36 ` [PATCH 1/1] MAINTAINERS: introduce cve or " P J P
@ 2020-07-14  9:46 ` Michael S. Tsirkin
  1 sibling, 0 replies; 28+ messages in thread
From: Michael S. Tsirkin @ 2020-07-14  9:46 UTC (permalink / raw)
  To: P J P
  Cc: Kevin Wolf, Peter Maydell, Stefano Stabellini,
	Daniel P . Berrange, Prasad J Pandit, Christian Schoenebeck,
	QEMU Developers, Michael Roth, Greg Kurz, Stefan Hajnoczi,
	Paolo Bonzini

On Tue, Jul 14, 2020 at 02:06:30PM +0530, P J P wrote:
> From: Prasad J Pandit <pjp@fedoraproject.org>
> 
> Hello,
> 
> QEMU supports numerous virtualisation and emulation use cases.
> It offers many features to support guest's function(s).
> 
> All of these use cases and features are not always security relevant.
> Because some maybe used in trusted environments only. Some may still
> be in experimental stage. While other could be very old and not
> used or maintained actively.
> 
> Recently we received multiple security issue reports against VVFAT
> and VirtFS host directory sharing system. After discussing with the
> respective maintainers, it turned out that
> 
> * VVFAT -> https://bugs.launchpad.net/qemu/+bug/1883083
>   VVFAT is quite old and is available for testing purposes only.
>   Ie. It is not suitable for production environments.
> 
> * VirtFS/9pfs -> https://wiki.qemu.org/Documentation/9psetup
>   VirtFS implementation though better, it is most commonly used for
>   automated testing under sand-boxed server environments, ie. no
>   malicious party there. It is also not mature enough for cloud services.
>   It is supported on 'Odd Fixes' basis atm.
> 
> So these turned out to be issues which can be fixed as regular bugs.
> 
> For security bug analysis we generally consider use cases wherein
> QEMU is used in conjunction with the KVM hypervisor, which enables
> guest to use hardware processor's virtualisation features.
> 
> This patch introduces the CVE (or Security or Trust) Quotient field
> in the MAINTAINERS file. It tries to capture the security sensitivity
> pertaining to a feature or section of the QEMU's code base.
> 
> It indicates whether a potential issue should be treated as a security
> one OR it could be fixed as a regular non-security bug.
> 
>     If Quotient == High, triage issues as potential security ones.
>     if Quotient == Low,  triage issues as regular non-security bugs.
> 
> I have tagged each section in the MAINTAINERS file as High or Low on best
> guess basis. I request respective maintainers to kindly review it please.
> 
> If you have any inputs/suggestions, I'd really appreciate them.
> 
> Thank you.

So this attempts to specify a security aspect of specific files.
Which works for some use-cases (e.g. devices) but not others
(common utility functions).

I'd like to propose add a flag that limits QEMU to a secured subset
of functionality at runtime instead.
Then we can just tell security researchers "reproduce this with
-security=high or it's not a security issue".


> --
> Prasad J Pandit (1):
>   MAINTAINERS: introduce cve or security quotient field
> 
>  MAINTAINERS | 324 ++++++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 324 insertions(+)
> 
> --
> 2.26.2



^ permalink raw reply	[flat|nested] 28+ messages in thread
* Re: [PATCH 1/1] MAINTAINERS: introduce cve or security quotient field
  2020-07-14  9:42   ` Peter Maydell
@ 2020-07-14  9:52     ` Daniel P. Berrangé
  2020-07-14 10:12       ` Michael S. Tsirkin
  0 siblings, 1 reply; 28+ messages in thread
From: Daniel P. Berrangé @ 2020-07-14  9:52 UTC (permalink / raw)
  To: Peter Maydell
  Cc: Kevin Wolf, Stefano Stabellini, Prasad J Pandit,
	Michael S . Tsirkin, QEMU Developers, Christian Schoenebeck,
	Michael Roth, P J P, Greg Kurz, Stefan Hajnoczi, Paolo Bonzini

On Tue, Jul 14, 2020 at 10:42:55AM +0100, Peter Maydell wrote:
> On Tue, 14 Jul 2020 at 09:40, P J P <ppandit@redhat.com> wrote:
> >
> > From: Prasad J Pandit <pjp@fedoraproject.org>
> >
> > QEMU supports numerous virtualisation and emulation use cases.
> > It also offers many features to support guest's function(s).
> >
> > All of these use cases and features are not always security relevant.
> > Because some maybe used in trusted environments only. Some may still
> > be in experimental stage. While other could be very old and not
> > used or maintained actively.
> >
> > For security bug analysis we generally consider use cases wherein
> > QEMU is used in conjunction with the KVM hypervisor, which enables
> > guest to use hardware processor's virtualisation features.
> >
> > The CVE (or Security or Trust) Quotient field tries to capture this
> > sensitivity pertaining to a feature or section of the code.
> >
> > It indicates whether a potential issue should be treated as a security
> > one OR it could be fixed as a regular non-security bug.
> 
> How does this interact with the way we already document our
> level of security support in docs/system/security.rst ?
> 
> > +       C: CVE/Security/Trust Quotient
> > +          H:High - Feature (or code) is meant to be safe and used by untrusted
> > +                   guests. So any potential security issue must be processed with
> > +                   due care and be considered as a CVE issue.
> > +          L:Low  - Feature (or code) is not meant to be safe OR is experimental
> > +                   OR is used in trusted environments only OR is not well
> > +                   maintained. So any potential security issue can be processed
> > +                   and fixed as regular non-security bug. No need for a CVE.
> 
> The difficulty with this is that MAINTAINERS is not set up
> with a split between "security issues" and "non-security
> issues". For instance this stanza:
> 
> > @@ -149,6 +161,7 @@ ARM TCG CPUs
> >  M: Peter Maydell <peter.maydell@linaro.org>
> >  L: qemu-arm@nongnu.org
> >  S: Maintained
> > +C: Low
> >  F: target/arm/
> >  F: tests/tcg/arm/
> >  F: tests/tcg/aarch64/
> 
> you have marked "Low", but the files it covers include
> both ones used by TCG (not security-critical) and ones
> used by KVM (security-critical).
> 
> Also, MAINTAINERS is not user-facing. If we want to say
> that vvfat or 9pfs are not suitable for use on a security
> boundary and that we do not consider bugs in them to
> be security issues, we should do that in the user-facing
> documentation.
> 
> Broadly speaking, it feels like you're trying to come up
> with an automatic way to say "does this patch touch a
> security-relevant part of the code", and I'm not sure
> that that's possible.

I agree that it isn't possible in the MAINTAINERS file, as the level
of granularity is a very poor match for what we want to express.

My high level thought would be that we should ultimately be able to
have a build flag to request only security-critical code is built
into the binaries.

This is probably a bit too much of a stretch goal right now, but it
at least points towards maintaining the information on a per-file
level of granularity. There might be some individual files which
currently contain a mix security-critical/not-security critical
code. Either they can be split eventually, or we can simply declare
that the entire file is none the less security critical.

We could perhaps have a magic comment at the top of each file that
is security critical. eg

 /* @security: maintained */

we don't need any comment in files we consider non-maintained from
a security POV.  Eventually we could do some (insert hand waving)
magic in meson to pull out this list of comments and use it to
exclude build of files that are not security critical. Maybe we
find out that using a magic comment isn't the best option, but
at least if we start now by keeping a per-file comment, we can
probably do an automated transformation to any other data storage
later.

Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|



^ permalink raw reply	[flat|nested] 28+ messages in thread
* Re: [PATCH 1/1] MAINTAINERS: introduce cve or security quotient field
  2020-07-14  9:52     ` Daniel P. Berrangé
@ 2020-07-14 10:12       ` Michael S. Tsirkin
  2020-07-14 10:22         ` Peter Maydell
  0 siblings, 1 reply; 28+ messages in thread
From: Michael S. Tsirkin @ 2020-07-14 10:12 UTC (permalink / raw)
  To: Daniel P. Berrangé
  Cc: Kevin Wolf, Peter Maydell, Stefano Stabellini, Prasad J Pandit,
	QEMU Developers, Christian Schoenebeck, Michael Roth, P J P,
	Greg Kurz, Stefan Hajnoczi, Paolo Bonzini

On Tue, Jul 14, 2020 at 10:52:33AM +0100, Daniel P. Berrangé wrote:
> On Tue, Jul 14, 2020 at 10:42:55AM +0100, Peter Maydell wrote:
> > On Tue, 14 Jul 2020 at 09:40, P J P <ppandit@redhat.com> wrote:
> > >
> > > From: Prasad J Pandit <pjp@fedoraproject.org>
> > >
> > > QEMU supports numerous virtualisation and emulation use cases.
> > > It also offers many features to support guest's function(s).
> > >
> > > All of these use cases and features are not always security relevant.
> > > Because some maybe used in trusted environments only. Some may still
> > > be in experimental stage. While other could be very old and not
> > > used or maintained actively.
> > >
> > > For security bug analysis we generally consider use cases wherein
> > > QEMU is used in conjunction with the KVM hypervisor, which enables
> > > guest to use hardware processor's virtualisation features.
> > >
> > > The CVE (or Security or Trust) Quotient field tries to capture this
> > > sensitivity pertaining to a feature or section of the code.
> > >
> > > It indicates whether a potential issue should be treated as a security
> > > one OR it could be fixed as a regular non-security bug.
> > 
> > How does this interact with the way we already document our
> > level of security support in docs/system/security.rst ?
> > 
> > > +       C: CVE/Security/Trust Quotient
> > > +          H:High - Feature (or code) is meant to be safe and used by untrusted
> > > +                   guests. So any potential security issue must be processed with
> > > +                   due care and be considered as a CVE issue.
> > > +          L:Low  - Feature (or code) is not meant to be safe OR is experimental
> > > +                   OR is used in trusted environments only OR is not well
> > > +                   maintained. So any potential security issue can be processed
> > > +                   and fixed as regular non-security bug. No need for a CVE.
> > 
> > The difficulty with this is that MAINTAINERS is not set up
> > with a split between "security issues" and "non-security
> > issues". For instance this stanza:
> > 
> > > @@ -149,6 +161,7 @@ ARM TCG CPUs
> > >  M: Peter Maydell <peter.maydell@linaro.org>
> > >  L: qemu-arm@nongnu.org
> > >  S: Maintained
> > > +C: Low
> > >  F: target/arm/
> > >  F: tests/tcg/arm/
> > >  F: tests/tcg/aarch64/
> > 
> > you have marked "Low", but the files it covers include
> > both ones used by TCG (not security-critical) and ones
> > used by KVM (security-critical).
> > 
> > Also, MAINTAINERS is not user-facing. If we want to say
> > that vvfat or 9pfs are not suitable for use on a security
> > boundary and that we do not consider bugs in them to
> > be security issues, we should do that in the user-facing
> > documentation.
> > 
> > Broadly speaking, it feels like you're trying to come up
> > with an automatic way to say "does this patch touch a
> > security-relevant part of the code", and I'm not sure
> > that that's possible.
> 
> I agree that it isn't possible in the MAINTAINERS file, as the level
> of granularity is a very poor match for what we want to express.
> 
> My high level thought would be that we should ultimately be able to
> have a build flag to request only security-critical code is built
> into the binaries.

And for people who want to build QEMU with lots of functionality (like
Fedora does), I think a -security flag would be a useful addition.
We can then tell security researchers "only a high security issue
if it reproduces with -security=high, only a security issue
if it reproduces with -security=low".


> This is probably a bit too much of a stretch goal right now, but it
> at least points towards maintaining the information on a per-file
> level of granularity. There might be some individual files which
> currently contain a mix security-critical/not-security critical
> code. Either they can be split eventually, or we can simply declare
> that the entire file is none the less security critical.
> 
> We could perhaps have a magic comment at the top of each file that
> is security critical. eg
> 
>  /* @security: maintained */
> 
> we don't need any comment in files we consider non-maintained from
> a security POV.  Eventually we could do some (insert hand waving)
> magic in meson to pull out this list of comments and use it to
> exclude build of files that are not security critical. Maybe we
> find out that using a magic comment isn't the best option, but
> at least if we start now by keeping a per-file comment, we can
> probably do an automated transformation to any other data storage
> later.
> 
> Daniel
> -- 
> |: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org         -o-            https://fstop138.berrange.com :|
> |: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|



^ permalink raw reply	[flat|nested] 28+ messages in thread
* Re: [PATCH 1/1] MAINTAINERS: introduce cve or security quotient field
  2020-07-14  8:36 ` [PATCH 1/1] MAINTAINERS: introduce cve or " P J P
  2020-07-14  9:42   ` Peter Maydell
@ 2020-07-14 10:18   ` Philippe Mathieu-Daudé
  2020-07-14 11:51   ` Cornelia Huck
  2020-07-16  8:56   ` Dr. David Alan Gilbert
  3 siblings, 0 replies; 28+ messages in thread
From: Philippe Mathieu-Daudé @ 2020-07-14 10:18 UTC (permalink / raw)
  To: P J P, Michael S . Tsirkin, Daniel P . Berrange
  Cc: Kevin Wolf, Peter Maydell, Stefano Stabellini, Prasad J Pandit,
	Christian Schoenebeck, Michael Roth, QEMU Developers, Greg Kurz,
	Stefan Hajnoczi, Paolo Bonzini

Hi Prasad,

On 7/14/20 10:36 AM, P J P wrote:
> From: Prasad J Pandit <pjp@fedoraproject.org>
> 
> QEMU supports numerous virtualisation and emulation use cases.
> It also offers many features to support guest's function(s).
> 
> All of these use cases and features are not always security relevant.
> Because some maybe used in trusted environments only. Some may still
> be in experimental stage. While other could be very old and not
> used or maintained actively.
> 
> For security bug analysis we generally consider use cases wherein
> QEMU is used in conjunction with the KVM hypervisor, which enables
> guest to use hardware processor's virtualisation features.
> 
> The CVE (or Security or Trust) Quotient field tries to capture this
> sensitivity pertaining to a feature or section of the code.
> 
> It indicates whether a potential issue should be treated as a security
> one OR it could be fixed as a regular non-security bug.
> 
> Suggested-by: Daniel P. Berrange <berrange@redhat.com>
> Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org>
> ---
>  MAINTAINERS | 324 ++++++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 324 insertions(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index fe8139f367..badf1dab6e 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -33,6 +33,14 @@ Descriptions of section entries:
>  	   Obsolete:	Old code. Something tagged obsolete generally means
>  			it has been replaced by a better system and you
>  			should be using that.
> +	C: CVE/Security/Trust Quotient
> +	   H:High - Feature (or code) is meant to be safe and used by untrusted
> +	            guests. So any potential security issue must be processed with
> +	            due care and be considered as a CVE issue.
> +	   L:Low  - Feature (or code) is not meant to be safe OR is experimental
> +	            OR is used in trusted environments only OR is not well
> +	            maintained. So any potential security issue can be processed
> +	            and fixed as regular non-security bug. No need for a CVE.

I'm not sure we need this separation of good/bad citizen.

We already have the 'S' flag:

        S: Status, one of the following:
           Supported:   Someone is actually paid to look after this.
           Maintained:  Someone actually looks after it.
           Odd Fixes:   It has a maintainer but they don't have time to
                        do much other than throw the odd patch in. See
                        below.
           Orphan:      No current maintainer [but maybe you could take
                        the role as you write your new code].
           Obsolete:    Old code. Something tagged obsolete generally
                        means it has been replaced by a better system
                        and you should be using that.

I think the 'Supported' status already describes a feature that
important enough to a company to have an employee looking at it.

If a section is not 'Supported', it is unlikely the maintainer
have time to deal with security issues.

I disagree with the High/Low tag, but I still reviewed the rest.

>  	F: Files and directories with wildcard patterns.
>  	   A trailing slash includes all files and subdirectory files.
>  	   F:	drivers/net/	all files in and below drivers/net
> @@ -87,6 +95,7 @@ S390 general architecture support
>  M: Cornelia Huck <cohuck@redhat.com>
>  M: Thomas Huth <thuth@redhat.com>
>  S: Supported
> +C: High
>  F: default-configs/s390x-softmmu.mak
>  F: gdb-xml/s390*.xml
>  F: hw/char/sclp*.[hc]

> @@ -149,6 +161,7 @@ ARM TCG CPUs
>  M: Peter Maydell <peter.maydell@linaro.org>
>  L: qemu-arm@nongnu.org
>  S: Maintained
> +C: Low
>  F: target/arm/

There is KVM code there.

>  F: tests/tcg/arm/
>  F: tests/tcg/aarch64/
> @@ -164,6 +177,7 @@ ARM SMMU
>  M: Eric Auger <eric.auger@redhat.com>
>  L: qemu-arm@nongnu.org
>  S: Maintained
> +C: High
>  F: hw/arm/smmu*
>  F: include/hw/arm/smmu*
>  
...

> @@ -270,6 +294,7 @@ PowerPC TCG CPUs
>  M: David Gibson <david@gibson.dropbear.id.au>
>  L: qemu-ppc@nongnu.org
>  S: Maintained
> +C: High

You might want to split this section in 2 to keep various
areas in Low.

>  F: target/ppc/
>  F: hw/ppc/
>  F: include/hw/ppc/
...

> @@ -440,6 +482,7 @@ M: Cameron Esfahani <dirty@apple.com>
>  M: Roman Bolshakov <r.bolshakov@yadro.com>
>  W: https://wiki.qemu.org/Features/HVF
>  S: Maintained
> +C: Low
>  F: accel/stubs/hvf-stub.c
>  F: target/i386/hvf/
>  F: include/sysemu/hvf.h
> @@ -447,6 +490,7 @@ F: include/sysemu/hvf.h
>  WHPX CPUs
>  M: Sunil Muthuswamy <sunilmut@microsoft.com>
>  S: Supported
> +C: Low

I think this is High.

>  F: target/i386/whpx-all.c
>  F: target/i386/whp-dispatch.h
>  F: accel/stubs/whpx-stub.c
> @@ -460,6 +504,7 @@ M: Anthony Perard <anthony.perard@citrix.com>
>  M: Paul Durrant <paul@xen.org>
>  L: xen-devel@lists.xenproject.org
>  S: Supported
> +C: High
>  F: */xen*
>  F: accel/xen/*
>  F: hw/9pfs/xen-9p*
> @@ -486,6 +531,7 @@ M: Colin Xu <colin.xu@intel.com>
>  L: haxm-team@intel.com
>  W: https://github.com/intel/haxm/issues
>  S: Maintained
> +C: Low

Ditto.

>  F: accel/stubs/hax-stub.c
>  F: include/sysemu/hax.h
>  F: target/i386/hax-*
> @@ -497,12 +543,14 @@ M: Michael S. Tsirkin <mst@redhat.com>
>  M: Cornelia Huck <cohuck@redhat.com>
>  M: Paolo Bonzini <pbonzini@redhat.com>
>  S: Maintained
> +C: High
>  F: linux-headers/
>  F: scripts/update-linux-headers.sh
...
> @@ -1631,11 +1782,13 @@ Character devices
>  M: Marc-André Lureau <marcandre.lureau@redhat.com>
>  R: Paolo Bonzini <pbonzini@redhat.com>
>  S: Odd Fixes
> +C: High
>  F: hw/char/
>  
>  Network devices
>  M: Jason Wang <jasowang@redhat.com>
>  S: Odd Fixes
> +C: High
>  F: hw/net/
>  F: include/hw/net/
>  F: tests/qtest/virtio-net-test.c

These two don't make sense to me. You can not be low class citizen
only maintained for 'Odd Fixes' and aim for security. Choose one.

>  SD (Secure Card)
>  M: Philippe Mathieu-Daudé <f4bug@amsat.org>
>  S: Odd Fixes
> +C: Low
>  F: include/hw/sd/sd*
>  F: hw/sd/core.c
>  F: hw/sd/sd*
> @@ -1684,6 +1842,7 @@ F: tests/qtest/sd*
>  USB
>  M: Gerd Hoffmann <kraxel@redhat.com>
>  S: Maintained
> +C: High
>  F: hw/usb/*

Similarly to PPC, you might want to split this one to reduce
coverage.

>  F: tests/qtest/usb-*-test.c
>  F: docs/usb2.txt
> @@ -1696,11 +1855,13 @@ USB (serial adapter)
>  M: Gerd Hoffmann <kraxel@redhat.com>
>  M: Samuel Thibault <samuel.thibault@ens-lyon.org>
>  S: Maintained
> +C: High
>  F: hw/usb/dev-serial.c
...

>  tulip
>  M: Sven Schnelle <svens@stackframe.org>
>  S: Maintained
> +C: High

Low.

>  F: hw/net/tulip.c
>  F: hw/net/tulip.h
>  
>  Generic Loader
>  M: Alistair Francis <alistair@alistair23.me>
>  S: Maintained
> +C: High
>  F: hw/core/generic-loader.c
>  F: include/hw/core/generic-loader.h
>  F: docs/generic-loader.txt

I'm not sure about this one.

> @@ -1921,12 +2108,14 @@ F: docs/generic-loader.txt
>  Intel Hexadecimal Object File Loader
>  M: Su Hang <suhang16@mails.ucas.ac.cn>
>  S: Maintained
> +C: Low
>  F: tests/qtest/hexloader-test.c
>  F: tests/data/hex-loader/test.hex
...

>  EDID Generator
>  M: Gerd Hoffmann <kraxel@redhat.com>
>  S: Maintained
> +C: Low
>  F: hw/display/edid*
>  F: include/hw/display/edid.h
>  F: qemu-edid.c

I'm not sure, but maybe.

> @@ -2012,6 +2211,7 @@ PIIX4 South Bridge (i82371AB)
>  M: Hervé Poussineau <hpoussin@reactos.org>
>  M: Philippe Mathieu-Daudé <f4bug@amsat.org>
>  S: Maintained
> +C: High

No, this one is low (which is why it has is own section,
to not bother MST).

>  F: hw/isa/piix4.c
>  F: include/hw/southbridge/piix.h
...

>  Device Tree
>  M: Alistair Francis <alistair.francis@wdc.com>
>  R: David Gibson <david@gibson.dropbear.id.au>
>  S: Maintained
> +C: Low
>  F: device_tree.c
>  F: include/sysemu/device_tree.h

This one is consumed by the Virt machine, maybe High?

>  
>  Dump
>  S: Supported
> +C: Low
>  M: Marc-André Lureau <marcandre.lureau@redhat.com>
>  F: dump/
>  F: hw/misc/vmcoreinfo.c
...

>  QObject
>  M: Markus Armbruster <armbru@redhat.com>
>  S: Supported
> +C: Low
>  F: qobject/
>  F: include/qapi/qmp/
>  X: include/qapi/qmp/dispatch.h

Low? Odd.

> @@ -2385,6 +2620,7 @@ T: git https://repo.or.cz/qemu/armbru.git qapi-next
>  QEMU Guest Agent
>  M: Michael Roth <mdroth@linux.vnet.ibm.com>
>  S: Maintained
> +C: Low

Odd too.

>  F: qga/
>  F: docs/interop/qemu-ga.rst
>  F: scripts/qemu-guest-agent/
> @@ -2397,6 +2633,7 @@ M: Paolo Bonzini <pbonzini@redhat.com>
>  R: Daniel P. Berrange <berrange@redhat.com>
>  R: Eduardo Habkost <ehabkost@redhat.com>
>  S: Supported
> +C: High
>  F: docs/qdev-device-use.txt
>  F: hw/core/qdev*
>  F: hw/core/bus.c
...

>  Register API
>  M: Alistair Francis <alistair@alistair23.me>
>  S: Maintained
> +C: High

No, Low.

>  F: hw/core/register.c
>  F: include/hw/register.h
>  F: include/hw/registerfields.h
> @@ -2456,6 +2697,7 @@ F: include/hw/registerfields.h
...

>  Tracing
>  M: Stefan Hajnoczi <stefanha@redhat.com>
>  S: Maintained
> +C: Low

Some backends are High.

>  F: trace/
>  F: trace-events
>  F: docs/qemu-option-trace.rst.inc
> @@ -2488,6 +2733,7 @@ T: git https://github.com/stefanha/qemu.git tracing
>  TPM
>  M: Stefan Berger <stefanb@linux.ibm.com>
>  S: Maintained
> +C: Low

High!!!

>  F: tpm.c
>  F: stubs/tpm.c
>  F: hw/tpm/*
> @@ -2500,12 +2746,14 @@ T: git https://github.com/stefanberger/qemu-tpm.git tpm-next
...

> @@ -2601,6 +2859,7 @@ L: qemu-block@nongnu.org
>  UUID
>  M: Fam Zheng <fam@euphon.net>
>  S: Supported
> +C: Low

High?

>  F: util/uuid.c
>  F: include/qemu/uuid.h
>  F: tests/test-uuid.c
> @@ -2608,6 +2867,7 @@ F: tests/test-uuid.c
...

>  Null Block Driver
>  M: Fam Zheng <fam@euphon.net>
>  L: qemu-block@nongnu.org
>  S: Supported
> +C: Low

High?

>  F: block/null.c
>  
>  NVMe Block Driver
>  M: Fam Zheng <fam@euphon.net>
>  L: qemu-block@nongnu.org
>  S: Supported
> +C: Low

Certainly High.

>  F: block/nvme*
>  
>  Bootdevice
>  M: Gonglei <arei.gonglei@huawei.com>
>  S: Maintained
> +C: Low
>  F: bootdevice.c
...

>  Replication
>  M: Wen Congyang <wencongyang2@huawei.com>
>  M: Xie Changlong <xiechanglong.d@gmail.com>
>  S: Supported
> +C: Low

High?

>  F: replication*
>  F: block/replication.c
>  F: tests/test-replication.c
> @@ -2997,6 +3309,7 @@ PVRDMA
>  M: Yuval Shaia <yuval.shaia.ml@gmail.com>
>  M: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
>  S: Maintained
> +C: High
>  F: hw/rdma/*
>  F: hw/rdma/vmw/*
>  F: docs/pvrdma.txt
...



^ permalink raw reply	[flat|nested] 28+ messages in thread
* Re: [PATCH 1/1] MAINTAINERS: introduce cve or security quotient field
  2020-07-14 10:12       ` Michael S. Tsirkin
@ 2020-07-14 10:22         ` Peter Maydell
  2020-07-14 11:02           ` Michael S. Tsirkin
  0 siblings, 1 reply; 28+ messages in thread
From: Peter Maydell @ 2020-07-14 10:22 UTC (permalink / raw)
  To: Michael S. Tsirkin
  Cc: Kevin Wolf, Stefano Stabellini, Daniel P. Berrangé,
	Prasad J Pandit, QEMU Developers, Christian Schoenebeck,
	Michael Roth, P J P, Greg Kurz, Stefan Hajnoczi, Paolo Bonzini

On Tue, 14 Jul 2020 at 11:12, Michael S. Tsirkin <mst@redhat.com> wrote:
> And for people who want to build QEMU with lots of functionality (like
> Fedora does), I think a -security flag would be a useful addition.
> We can then tell security researchers "only a high security issue
> if it reproduces with -security=high, only a security issue
> if it reproduces with -security=low".

I think a -security option would also be useful to users -- it
makes it easier for them to check "is this configuration using
something that I didn't realize was not intended to be secure".
For me, something useful for our users is much more compelling
than "this might make security researchers' lives a bit easier".

thanks
-- PMM


^ permalink raw reply	[flat|nested] 28+ messages in thread
* Re: [PATCH 1/1] MAINTAINERS: introduce cve or security quotient field
  2020-07-14 10:22         ` Peter Maydell
@ 2020-07-14 11:02           ` Michael S. Tsirkin
  2020-07-14 13:10             ` P J P
  2020-07-14 13:30             ` Daniel P. Berrangé
  0 siblings, 2 replies; 28+ messages in thread
From: Michael S. Tsirkin @ 2020-07-14 11:02 UTC (permalink / raw)
  To: Peter Maydell
  Cc: Kevin Wolf, Stefano Stabellini, Daniel P. Berrangé,
	Prasad J Pandit, QEMU Developers, Christian Schoenebeck,
	Michael Roth, P J P, Greg Kurz, Stefan Hajnoczi, Paolo Bonzini

On Tue, Jul 14, 2020 at 11:22:28AM +0100, Peter Maydell wrote:
> On Tue, 14 Jul 2020 at 11:12, Michael S. Tsirkin <mst@redhat.com> wrote:
> > And for people who want to build QEMU with lots of functionality (like
> > Fedora does), I think a -security flag would be a useful addition.
> > We can then tell security researchers "only a high security issue
> > if it reproduces with -security=high, only a security issue
> > if it reproduces with -security=low".
> 
> I think a -security option would also be useful to users -- it
> makes it easier for them to check "is this configuration using
> something that I didn't realize was not intended to be secure".
> For me, something useful for our users is much more compelling
> than "this might make security researchers' lives a bit easier".
> 
> thanks
> -- PMM

True. And I guess downstreams can also force the option to high or set the
default to high rather easily if they want to.

So the option would be:

-security level
	Set minimal required security level of QEMU.

	high: block use of QEMU functionality which is intended to be secure against
		malicious guests.
	low: allow use of all QEMU functionality, best effort security
		against malicious guests.

Default would be -security low.

Does this look reasonable?

Just a correction to what I wrote: I no longer think it's reasonable to
classify the severity of a security issue automatically. E.g. a qemu
crash in virtio code is a high severity security issue if it triggers
with platform_iommu=on since it is then driver from guest userspace, and
low severity one without since then it's driven from a guest driver.

So I think we can add something like this to security.rst and to
the wiki:

	only a security issue if it
	reproduces with -security high, a regular bug if it only reproduces with
	-security low

Prasad?

-- 
MST



^ permalink raw reply	[flat|nested] 28+ messages in thread
* Re: [PATCH 1/1] MAINTAINERS: introduce cve or security quotient field
  2020-07-14  8:36 ` [PATCH 1/1] MAINTAINERS: introduce cve or " P J P
  2020-07-14  9:42   ` Peter Maydell
  2020-07-14 10:18   ` Philippe Mathieu-Daudé
@ 2020-07-14 11:51   ` Cornelia Huck
  2020-07-16  8:56   ` Dr. David Alan Gilbert
  3 siblings, 0 replies; 28+ messages in thread
From: Cornelia Huck @ 2020-07-14 11:51 UTC (permalink / raw)
  To: P J P
  Cc: Kevin Wolf, Peter Maydell, Stefano Stabellini,
	Daniel P . Berrange, Prasad J Pandit, Michael S . Tsirkin,
	Christian Schoenebeck, Michael Roth, QEMU Developers, Greg Kurz,
	Stefan Hajnoczi, Paolo Bonzini

On Tue, 14 Jul 2020 14:06:31 +0530
P J P <ppandit@redhat.com> wrote:

> From: Prasad J Pandit <pjp@fedoraproject.org>
> 
> QEMU supports numerous virtualisation and emulation use cases.
> It also offers many features to support guest's function(s).
> 
> All of these use cases and features are not always security relevant.
> Because some maybe used in trusted environments only. Some may still
> be in experimental stage. While other could be very old and not
> used or maintained actively.
> 
> For security bug analysis we generally consider use cases wherein
> QEMU is used in conjunction with the KVM hypervisor, which enables
> guest to use hardware processor's virtualisation features.
> 
> The CVE (or Security or Trust) Quotient field tries to capture this
> sensitivity pertaining to a feature or section of the code.
> 
> It indicates whether a potential issue should be treated as a security
> one OR it could be fixed as a regular non-security bug.
> 
> Suggested-by: Daniel P. Berrange <berrange@redhat.com>
> Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org>
> ---
>  MAINTAINERS | 324 ++++++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 324 insertions(+)
> 

(...)

> @@ -87,6 +95,7 @@ S390 general architecture support
>  M: Cornelia Huck <cohuck@redhat.com>
>  M: Thomas Huth <thuth@redhat.com>
>  S: Supported
> +C: High

Just to reiterate what others have previously stated:

The granularity in MAINTAINERS and how it is organized does not really
work well with what you are trying to do with this classification.

If I pick just this entry as an example: It covers *all* s390x-related
code, and this covers both things like support for protected
virtualization (definitely critical) and virtio-9p-ccw (definitely not
critical). It is important that somebody is looking after s390x overall
(hence the "Supported" state), but not all s390x-related code is
equally critical.

I see the main purpose of the MAINTAINERS file to find the right
contacts for an area; other approaches like tagging of devices and
features seem to be better suited for figuring out which areas are
deemed critical.

>  F: default-configs/s390x-softmmu.mak
>  F: gdb-xml/s390*.xml
>  F: hw/char/sclp*.[hc]



^ permalink raw reply	[flat|nested] 28+ messages in thread
* Re: [PATCH 1/1] MAINTAINERS: introduce cve or security quotient field
  2020-07-14 11:02           ` Michael S. Tsirkin
@ 2020-07-14 13:10             ` P J P
  2020-07-16  6:55               ` Cornelia Huck
  2020-07-14 13:30             ` Daniel P. Berrangé
  1 sibling, 1 reply; 28+ messages in thread
From: P J P @ 2020-07-14 13:10 UTC (permalink / raw)
  To: Michael S. Tsirkin
  Cc: Kevin Wolf, Peter Maydell, Stefano Stabellini,
	Daniel P. Berrangé,
	Cornelia Huck, Christian Schoenebeck, Michael Roth,
	QEMU Developers, Greg Kurz, Stefan Hajnoczi, Paolo Bonzini,
	Philippe Mathieu-Daudé

  Hello all,

Thank you so much for the comments and inptus, I appreciate it.

+-- On Tue, 14 Jul 2020, Michael S. Tsirkin wrote --+
| On Tue, Jul 14, 2020 at 11:22:28AM +0100, Peter Maydell wrote:
| > On Tue, 14 Jul 2020 at 11:12, Michael S. Tsirkin <mst@redhat.com> wrote:
| > > And for people who want to build QEMU with lots of functionality (like
| > > Fedora does), I think a -security flag would be a useful addition.
| > > We can then tell security researchers "only a high security issue
| > > if it reproduces with -security=high, only a security issue
| > > if it reproduces with -security=low".
| > 
| > I think a -security option would also be useful to users -- it makes it 
| > easier for them to check "is this configuration using something that I 
| > didn't realize was not intended to be secure". For me, something useful 
| > for our users is much more compelling than "this might make security 
| > researchers' lives a bit easier".

* General consensus seems to be that MAINTAINERS file is not best suited for 
  such security related annotation.

* We generally ask researchers if the issue is reproducible with 
  '-enable-kvm', so it excludes TCG use cases.


| -security level
| 	Set minimal required security level of QEMU.
| 
| 	high: block use of QEMU functionality which is intended to be secure against
| 	malicious guests.

   secure -> insecure, I think?

| 	low: allow use of all QEMU functionality, best effort security
| 		against malicious guests.
| 
| Default would be -security low.
| 
| Does this look reasonable?
| 
| Just a correction to what I wrote: I no longer think it's reasonable to
| classify the severity of a security issue automatically. E.g. a qemu
| crash in virtio code is a high severity security issue if it triggers
| with platform_iommu=on since it is then driver from guest userspace, and
| low severity one without since then it's driven from a guest driver.
| 
| So I think we can add something like this to security.rst and to
| the wiki:
| 
| 	only a security issue if it
| 	reproduces with -security high, a regular bug if it only reproduces with
| 	-security low
| 
| Prasad?

IIUC:

 * QEMU would abort(3), if a user attempts to start QEMU with insecure options 
   like say -virtfs OR -fda fat:floopy OR -netdev user OR -device tulip ?  

 * One way could be to abort(3) at options parsing stage, if 'security' flag 
   is set to high(1) and continue further if it is low(0).

 * ie. for each option we'd need do define if it is safe or not?

Does that seem right? OR do we maintain a run time list of features/options 
deemed to be safe? Either way, we need to define some place, which QEMU 
functions/devices/backends etc. are safe.


Thank you.
--
Prasad J Pandit / Red Hat Product Security Team
8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D



^ permalink raw reply	[flat|nested] 28+ messages in thread
* Re: [PATCH 1/1] MAINTAINERS: introduce cve or security quotient field
  2020-07-14 11:02           ` Michael S. Tsirkin
  2020-07-14 13:10             ` P J P
@ 2020-07-14 13:30             ` Daniel P. Berrangé
  2020-07-14 13:48               ` Kevin Wolf
  1 sibling, 1 reply; 28+ messages in thread
From: Daniel P. Berrangé @ 2020-07-14 13:30 UTC (permalink / raw)
  To: Michael S. Tsirkin
  Cc: Kevin Wolf, Peter Maydell, Stefano Stabellini, Prasad J Pandit,
	QEMU Developers, Christian Schoenebeck, Michael Roth, P J P,
	Greg Kurz, Stefan Hajnoczi, Paolo Bonzini

On Tue, Jul 14, 2020 at 07:02:59AM -0400, Michael S. Tsirkin wrote:
> On Tue, Jul 14, 2020 at 11:22:28AM +0100, Peter Maydell wrote:
> > On Tue, 14 Jul 2020 at 11:12, Michael S. Tsirkin <mst@redhat.com> wrote:
> > > And for people who want to build QEMU with lots of functionality (like
> > > Fedora does), I think a -security flag would be a useful addition.
> > > We can then tell security researchers "only a high security issue
> > > if it reproduces with -security=high, only a security issue
> > > if it reproduces with -security=low".
> > 
> > I think a -security option would also be useful to users -- it
> > makes it easier for them to check "is this configuration using
> > something that I didn't realize was not intended to be secure".
> > For me, something useful for our users is much more compelling
> > than "this might make security researchers' lives a bit easier".
> > 
> > thanks
> > -- PMM
> 
> True. And I guess downstreams can also force the option to high or set the
> default to high rather easily if they want to.
> 
> So the option would be:
> 
> -security level
> 	Set minimal required security level of QEMU.
> 
> 	high: block use of QEMU functionality which is intended to be secure against
> 		malicious guests.
> 	low: allow use of all QEMU functionality, best effort security
> 		against malicious guests.
> 
> Default would be -security low.
> 
> Does this look reasonable?

The challenge I see is that wiring up a runtime flag into every relevant
part of the QEMU codebase is an pretty large amount of work. Every device,
every machine type, every backend type, every generic subsystem will all
need checks for this flag. It is possible, but it isn't going to be quick
or easy, especially with poor error reporting support in many areas.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|



^ permalink raw reply	[flat|nested] 28+ messages in thread
* Re: [PATCH 1/1] MAINTAINERS: introduce cve or security quotient field
  2020-07-14 13:30             ` Daniel P. Berrangé
@ 2020-07-14 13:48               ` Kevin Wolf
  2020-07-14 13:56                 ` Thomas Huth
  2020-07-14 14:02                 ` Daniel P. Berrangé
  0 siblings, 2 replies; 28+ messages in thread
From: Kevin Wolf @ 2020-07-14 13:48 UTC (permalink / raw)
  To: Daniel P. Berrangé
  Cc: Peter Maydell, Stefano Stabellini, Prasad J Pandit,
	Michael S. Tsirkin, QEMU Developers, Christian Schoenebeck,
	Michael Roth, P J P, Greg Kurz, Stefan Hajnoczi, Paolo Bonzini

Am 14.07.2020 um 15:30 hat Daniel P. Berrangé geschrieben:
> On Tue, Jul 14, 2020 at 07:02:59AM -0400, Michael S. Tsirkin wrote:
> > On Tue, Jul 14, 2020 at 11:22:28AM +0100, Peter Maydell wrote:
> > > On Tue, 14 Jul 2020 at 11:12, Michael S. Tsirkin <mst@redhat.com> wrote:
> > > > And for people who want to build QEMU with lots of functionality (like
> > > > Fedora does), I think a -security flag would be a useful addition.
> > > > We can then tell security researchers "only a high security issue
> > > > if it reproduces with -security=high, only a security issue
> > > > if it reproduces with -security=low".
> > > 
> > > I think a -security option would also be useful to users -- it
> > > makes it easier for them to check "is this configuration using
> > > something that I didn't realize was not intended to be secure".
> > > For me, something useful for our users is much more compelling
> > > than "this might make security researchers' lives a bit easier".
> > > 
> > > thanks
> > > -- PMM
> > 
> > True. And I guess downstreams can also force the option to high or set the
> > default to high rather easily if they want to.
> > 
> > So the option would be:
> > 
> > -security level
> > 	Set minimal required security level of QEMU.
> > 
> > 	high: block use of QEMU functionality which is intended to be secure against
> > 		malicious guests.
> > 	low: allow use of all QEMU functionality, best effort security
> > 		against malicious guests.
> > 
> > Default would be -security low.
> > 
> > Does this look reasonable?
> 
> The challenge I see is that wiring up a runtime flag into every relevant
> part of the QEMU codebase is an pretty large amount of work. Every device,
> every machine type, every backend type, every generic subsystem will all
> need checks for this flag. It is possible, but it isn't going to be quick
> or easy, especially with poor error reporting support in many areas.

Would it make more sense as a configure flag that decides whether or not
to compile in potentially problematic devices/backends?

Kevin



^ permalink raw reply	[flat|nested] 28+ messages in thread
* Re: [PATCH 1/1] MAINTAINERS: introduce cve or security quotient field
  2020-07-14 13:48               ` Kevin Wolf
@ 2020-07-14 13:56                 ` Thomas Huth
  2020-07-14 15:04                   ` Christian Schoenebeck
  2020-07-14 14:02                 ` Daniel P. Berrangé
  1 sibling, 1 reply; 28+ messages in thread
From: Thomas Huth @ 2020-07-14 13:56 UTC (permalink / raw)
  To: Kevin Wolf, Daniel P. Berrangé
  Cc: Peter Maydell, Stefano Stabellini, Prasad J Pandit,
	Michael S. Tsirkin, Christian Schoenebeck, QEMU Developers,
	Michael Roth, Greg Kurz, Stefan Hajnoczi, Paolo Bonzini, P J P

On 14/07/2020 15.48, Kevin Wolf wrote:
> Am 14.07.2020 um 15:30 hat Daniel P. Berrangé geschrieben:
>> On Tue, Jul 14, 2020 at 07:02:59AM -0400, Michael S. Tsirkin wrote:
>>> On Tue, Jul 14, 2020 at 11:22:28AM +0100, Peter Maydell wrote:
>>>> On Tue, 14 Jul 2020 at 11:12, Michael S. Tsirkin <mst@redhat.com> wrote:
>>>>> And for people who want to build QEMU with lots of functionality (like
>>>>> Fedora does), I think a -security flag would be a useful addition.
>>>>> We can then tell security researchers "only a high security issue
>>>>> if it reproduces with -security=high, only a security issue
>>>>> if it reproduces with -security=low".
>>>>
>>>> I think a -security option would also be useful to users -- it
>>>> makes it easier for them to check "is this configuration using
>>>> something that I didn't realize was not intended to be secure".
>>>> For me, something useful for our users is much more compelling
>>>> than "this might make security researchers' lives a bit easier".
>>>>
>>>> thanks
>>>> -- PMM
>>>
>>> True. And I guess downstreams can also force the option to high or set the
>>> default to high rather easily if they want to.
>>>
>>> So the option would be:
>>>
>>> -security level
>>> 	Set minimal required security level of QEMU.
>>>
>>> 	high: block use of QEMU functionality which is intended to be secure against
>>> 		malicious guests.
>>> 	low: allow use of all QEMU functionality, best effort security
>>> 		against malicious guests.
>>>
>>> Default would be -security low.
>>>
>>> Does this look reasonable?
>>
>> The challenge I see is that wiring up a runtime flag into every relevant
>> part of the QEMU codebase is an pretty large amount of work. Every device,
>> every machine type, every backend type, every generic subsystem will all
>> need checks for this flag. It is possible, but it isn't going to be quick
>> or easy, especially with poor error reporting support in many areas.
> 
> Would it make more sense as a configure flag that decides whether or not
> to compile in potentially problematic devices/backends?

I guess there are users for both. Some people prefer to compile their
reduced QEMU binary (remember Nemu?), while the users from the normal
Linux distros might benefit more from a runtime switch, I guess.

I wonder whether it's somehow possible to unify both approaches, so that
we could mark the secure/insecure objects in the Makefiles already and
then either don't link them for the Nema-style users, or mark the
objects via some linker magic (?) as insecure, so we could flag them
during runtime if a certain parameter has been used...? No clue whether
that's possible at all, I'm just brainstorming...

 Thomas



^ permalink raw reply	[flat|nested] 28+ messages in thread
* Re: [PATCH 1/1] MAINTAINERS: introduce cve or security quotient field
  2020-07-14 13:48               ` Kevin Wolf
  2020-07-14 13:56                 ` Thomas Huth
@ 2020-07-14 14:02                 ` Daniel P. Berrangé
  1 sibling, 0 replies; 28+ messages in thread
From: Daniel P. Berrangé @ 2020-07-14 14:02 UTC (permalink / raw)
  To: Kevin Wolf
  Cc: Peter Maydell, Stefano Stabellini, Prasad J Pandit,
	Michael S. Tsirkin, Christian Schoenebeck, QEMU Developers,
	Michael Roth, Greg Kurz, Stefan Hajnoczi, Paolo Bonzini, P J P

On Tue, Jul 14, 2020 at 03:48:56PM +0200, Kevin Wolf wrote:
> Am 14.07.2020 um 15:30 hat Daniel P. Berrangé geschrieben:
> > On Tue, Jul 14, 2020 at 07:02:59AM -0400, Michael S. Tsirkin wrote:
> > > On Tue, Jul 14, 2020 at 11:22:28AM +0100, Peter Maydell wrote:
> > > > On Tue, 14 Jul 2020 at 11:12, Michael S. Tsirkin <mst@redhat.com> wrote:
> > > > > And for people who want to build QEMU with lots of functionality (like
> > > > > Fedora does), I think a -security flag would be a useful addition.
> > > > > We can then tell security researchers "only a high security issue
> > > > > if it reproduces with -security=high, only a security issue
> > > > > if it reproduces with -security=low".
> > > > 
> > > > I think a -security option would also be useful to users -- it
> > > > makes it easier for them to check "is this configuration using
> > > > something that I didn't realize was not intended to be secure".
> > > > For me, something useful for our users is much more compelling
> > > > than "this might make security researchers' lives a bit easier".
> > > > 
> > > > thanks
> > > > -- PMM
> > > 
> > > True. And I guess downstreams can also force the option to high or set the
> > > default to high rather easily if they want to.
> > > 
> > > So the option would be:
> > > 
> > > -security level
> > > 	Set minimal required security level of QEMU.
> > > 
> > > 	high: block use of QEMU functionality which is intended to be secure against
> > > 		malicious guests.
> > > 	low: allow use of all QEMU functionality, best effort security
> > > 		against malicious guests.
> > > 
> > > Default would be -security low.
> > > 
> > > Does this look reasonable?
> > 
> > The challenge I see is that wiring up a runtime flag into every relevant
> > part of the QEMU codebase is an pretty large amount of work. Every device,
> > every machine type, every backend type, every generic subsystem will all
> > need checks for this flag. It is possible, but it isn't going to be quick
> > or easy, especially with poor error reporting support in many areas.
> 
> Would it make more sense as a configure flag that decides whether or not
> to compile in potentially problematic devices/backends?

In the perfect world I think we need both because they satisfy different
scenarios.

There are people who are so paranoid they don't want the insecure code
compiled at all. They want a binary guaranteed to only have the trustworthy
code.

Then there are the people who just want protection against making silly
mistakes in their configuration, but want to be able choose between the
features at runtime.

For security researchers reporting issues, I think we already do enough
by documenting what we consider in / out of scope.  In most cases we
can quickly identify whether the reported flaw is in or out of scope.
So I wouldn't think too much about what to do for security researchers.

It is more productive to focus on what our real users needs.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|



^ permalink raw reply	[flat|nested] 28+ messages in thread
* Re: [PATCH 1/1] MAINTAINERS: introduce cve or security quotient field
  2020-07-14 13:56                 ` Thomas Huth
@ 2020-07-14 15:04                   ` Christian Schoenebeck
  0 siblings, 0 replies; 28+ messages in thread
From: Christian Schoenebeck @ 2020-07-14 15:04 UTC (permalink / raw)
  To: qemu-devel
  Cc: Thomas Huth, Kevin Wolf, Daniel P. Berrangé,
	Peter Maydell, Stefano Stabellini, Prasad J Pandit,
	Michael S. Tsirkin, Michael Roth, Greg Kurz, Stefan Hajnoczi,
	Paolo Bonzini, P J P

On Dienstag, 14. Juli 2020 15:56:24 CEST Thomas Huth wrote:
> >> The challenge I see is that wiring up a runtime flag into every relevant
> >> part of the QEMU codebase is an pretty large amount of work. Every
> >> device,
> >> every machine type, every backend type, every generic subsystem will all
> >> need checks for this flag. It is possible, but it isn't going to be quick
> >> or easy, especially with poor error reporting support in many areas.
> > 
> > Would it make more sense as a configure flag that decides whether or not
> > to compile in potentially problematic devices/backends?
> 
> I guess there are users for both. Some people prefer to compile their
> reduced QEMU binary (remember Nemu?), while the users from the normal
> Linux distros might benefit more from a runtime switch, I guess.
> 
> I wonder whether it's somehow possible to unify both approaches, so that
> we could mark the secure/insecure objects in the Makefiles already and
> then either don't link them for the Nema-style users, or mark the
> objects via some linker magic (?) as insecure, so we could flag them
> during runtime if a certain parameter has been used...? No clue whether
> that's possible at all, I'm just brainstorming...

Then what about new (i.e. experimental) features? Those would then need to be 
moved into separate objects for that, otherwise they would be handled with the 
same (high) security level. Moving them to other units complicates patches.

It might make sense being able to mark the security level of a unit, while 
also being able to override the security level of individual functions (i.e. 
by some magic macro, similar to existing macro 'coroutine_fn').

However despite the details, that concept in general has the limitation of 
being a somewhat undeterministic runtime feature; i.e. it might abort 
immediately (good) or who knows when (bad). Hence being able to also associate 
a security level with runtime parameters would be beneficial to cause the 
abortion to happen rather immediately.

Best regards,
Christian Schoenebeck




^ permalink raw reply	[flat|nested] 28+ messages in thread
* Re: [PATCH 1/1] MAINTAINERS: introduce cve or security quotient field
  2020-07-14 13:10             ` P J P
@ 2020-07-16  6:55               ` Cornelia Huck
  2020-07-16  8:36                 ` Daniel P. Berrangé
  0 siblings, 1 reply; 28+ messages in thread
From: Cornelia Huck @ 2020-07-16  6:55 UTC (permalink / raw)
  To: P J P
  Cc: Kevin Wolf, Peter Maydell, Stefano Stabellini,
	Daniel P. Berrangé,
	Michael S. Tsirkin, Christian Schoenebeck, Michael Roth,
	QEMU Developers, Greg Kurz, Stefan Hajnoczi, Paolo Bonzini,
	Philippe Mathieu-Daudé

On Tue, 14 Jul 2020 18:40:11 +0530 (IST)
P J P <ppandit@redhat.com> wrote:

<just commenting on this one>

>  * QEMU would abort(3), if a user attempts to start QEMU with insecure options 
>    like say -virtfs OR -fda fat:floopy OR -netdev user OR -device tulip ?  
> 
>  * One way could be to abort(3) at options parsing stage, if 'security' flag 
>    is set to high(1) and continue further if it is low(0).

Failing to start (with a message that explains why) if one of the
command line options is not covered by a specified security policy is
not unreasonable (after all, we fail to start for other cases of
incompatible command line options as well.) However, we also need to
cover dynamically-added devices. Aborting seems very bad there, just
failing to add the device seems like what we'd want.



^ permalink raw reply	[flat|nested] 28+ messages in thread
* Re: [PATCH 1/1] MAINTAINERS: introduce cve or security quotient field
  2020-07-16  6:55               ` Cornelia Huck
@ 2020-07-16  8:36                 ` Daniel P. Berrangé
  2020-07-16  9:21                   ` P J P
  0 siblings, 1 reply; 28+ messages in thread
From: Daniel P. Berrangé @ 2020-07-16  8:36 UTC (permalink / raw)
  To: Cornelia Huck
  Cc: Kevin Wolf, Peter Maydell, Stefano Stabellini,
	Michael S. Tsirkin, QEMU Developers, Christian Schoenebeck,
	Michael Roth, P J P, Greg Kurz, Stefan Hajnoczi, Paolo Bonzini,
	Philippe Mathieu-Daudé

On Thu, Jul 16, 2020 at 08:55:43AM +0200, Cornelia Huck wrote:
> On Tue, 14 Jul 2020 18:40:11 +0530 (IST)
> P J P <ppandit@redhat.com> wrote:
> 
> <just commenting on this one>
> 
> >  * QEMU would abort(3), if a user attempts to start QEMU with insecure options 
> >    like say -virtfs OR -fda fat:floopy OR -netdev user OR -device tulip ?  
> > 
> >  * One way could be to abort(3) at options parsing stage, if 'security' flag 
> >    is set to high(1) and continue further if it is low(0).
> 
> Failing to start (with a message that explains why) if one of the
> command line options is not covered by a specified security policy is
> not unreasonable (after all, we fail to start for other cases of
> incompatible command line options as well.) However, we also need to
> cover dynamically-added devices. Aborting seems very bad there, just
> failing to add the device seems like what we'd want.

Yep, aborting is simply not an option for the inner code. It all has to
propagate to a proper Error **errp object. The ultimate entry-point
at the CLI vs QMP then decides whether to turn the error into an abort
or feed back to the client app.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|



^ permalink raw reply	[flat|nested] 28+ messages in thread
* Re: [PATCH 1/1] MAINTAINERS: introduce cve or security quotient field
  2020-07-14  8:36 ` [PATCH 1/1] MAINTAINERS: introduce cve or " P J P
                     ` (2 preceding siblings ...)
  2020-07-14 11:51   ` Cornelia Huck
@ 2020-07-16  8:56   ` Dr. David Alan Gilbert
  2020-07-16  9:44     ` P J P
  3 siblings, 1 reply; 28+ messages in thread
From: Dr. David Alan Gilbert @ 2020-07-16  8:56 UTC (permalink / raw)
  To: P J P
  Cc: Kevin Wolf, Peter Maydell, Stefano Stabellini,
	Daniel P . Berrange, Prasad J Pandit, Michael S . Tsirkin,
	Christian Schoenebeck, Michael Roth, QEMU Developers, Greg Kurz,
	Stefan Hajnoczi, Paolo Bonzini

* P J P (ppandit@redhat.com) wrote:
> From: Prasad J Pandit <pjp@fedoraproject.org>
> 
> QEMU supports numerous virtualisation and emulation use cases.
> It also offers many features to support guest's function(s).
> 
> All of these use cases and features are not always security relevant.
> Because some maybe used in trusted environments only. Some may still
> be in experimental stage. While other could be very old and not
> used or maintained actively.
> 
> For security bug analysis we generally consider use cases wherein
> QEMU is used in conjunction with the KVM hypervisor, which enables
> guest to use hardware processor's virtualisation features.
> 
> The CVE (or Security or Trust) Quotient field tries to capture this
> sensitivity pertaining to a feature or section of the code.
> 
> It indicates whether a potential issue should be treated as a security
> one OR it could be fixed as a regular non-security bug.
> 
> Suggested-by: Daniel P. Berrange <berrange@redhat.com>
> Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org>
> ---
>  MAINTAINERS | 324 ++++++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 324 insertions(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index fe8139f367..badf1dab6e 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -33,6 +33,14 @@ Descriptions of section entries:
>  	   Obsolete:	Old code. Something tagged obsolete generally means
>  			it has been replaced by a better system and you
>  			should be using that.
> +	C: CVE/Security/Trust Quotient
> +	   H:High - Feature (or code) is meant to be safe and used by untrusted
> +	            guests. So any potential security issue must be processed with
> +	            due care and be considered as a CVE issue.
> +	   L:Low  - Feature (or code) is not meant to be safe OR is experimental
> +	            OR is used in trusted environments only OR is not well
> +	            maintained. So any potential security issue can be processed
> +	            and fixed as regular non-security bug. No need for a CVE.

That's a lot of OR's and it causes problems;
....

>  QMP
>  M: Markus Armbruster <armbru@redhat.com>
>  S: Supported
> +C: Low
>  F: monitor/monitor-internal.h
>  F: monitor/qmp*
>  F: monitor/misc.c

QMP is critical to many uses, so you wouldn't want to exclude it from a secure build;
any security issue with it (e.g. misparsing an argument) would be very
serious and would need to be looked at; but QMP is expected to be
talking to another trusted endpoint.

Dave
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK



^ permalink raw reply	[flat|nested] 28+ messages in thread
* Re: [PATCH 1/1] MAINTAINERS: introduce cve or security quotient field
  2020-07-16  8:36                 ` Daniel P. Berrangé
@ 2020-07-16  9:21                   ` P J P
  2020-07-16  9:39                     ` Daniel P. Berrangé
  2020-07-16  9:45                     ` Christian Schoenebeck
  0 siblings, 2 replies; 28+ messages in thread
From: P J P @ 2020-07-16  9:21 UTC (permalink / raw)
  To: Daniel P. Berrangé
  Cc: Kevin Wolf, Peter Maydell, Stefano Stabellini,
	Michael S. Tsirkin, Cornelia Huck, Christian Schoenebeck,
	Michael Roth, QEMU Developers, Greg Kurz, Stefan Hajnoczi,
	Paolo Bonzini, Philippe Mathieu-Daudé

[-- Attachment #1: Type: text/plain, Size: 1367 bytes --]

+-- On Thu, 16 Jul 2020, Daniel P. Berrangé wrote --+
| > Failing to start (with a message that explains why) if one of the command 
| > line options is not covered by a specified security policy is not 
| > unreasonable (after all, we fail to start for other cases of incompatible 
| > command line options as well.)

  Yes, that's right.

| > However, we also need to cover dynamically-added devices. Aborting seems 
| > very bad there, just failing to add the device seems like what we'd want.
| 
| Yep, aborting is simply not an option for the inner code. It all has to 
| propagate to a proper Error **errp object. The ultimate entry-point at the 
| CLI vs QMP then decides whether to turn the error into an abort or feed back 
| to the client app.

  True, handling dynamic devices is tricky.

Though it seems kind of uniform workflow to check for '--security' flag at 
options parsing OR while handling dynamic devices at run time; It is a huge 
task to cover all options/use-cases for all QEMU emulators across various 
architectures.

* If this approach is reasonable, I'll try to make an initial patch towards 
  it.

* We'd still need to figure out similar way for compile time option, to 
  exclude building insecure features at build time.


Thank you.
--
Prasad J Pandit / Red Hat Product Security Team
8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D

^ permalink raw reply	[flat|nested] 28+ messages in thread
* Re: [PATCH 1/1] MAINTAINERS: introduce cve or security quotient field
  2020-07-16  9:21                   ` P J P
@ 2020-07-16  9:39                     ` Daniel P. Berrangé
  2020-07-16  9:45                     ` Christian Schoenebeck
  1 sibling, 0 replies; 28+ messages in thread
From: Daniel P. Berrangé @ 2020-07-16  9:39 UTC (permalink / raw)
  To: P J P
  Cc: Kevin Wolf, Peter Maydell, Stefano Stabellini,
	Michael S. Tsirkin, Cornelia Huck, Christian Schoenebeck,
	Michael Roth, QEMU Developers, Greg Kurz, Stefan Hajnoczi,
	Paolo Bonzini, Philippe Mathieu-Daudé

On Thu, Jul 16, 2020 at 02:51:55PM +0530, P J P wrote:
> +-- On Thu, 16 Jul 2020, Daniel P. Berrangé wrote --+
> | > Failing to start (with a message that explains why) if one of the command 
> | > line options is not covered by a specified security policy is not 
> | > unreasonable (after all, we fail to start for other cases of incompatible 
> | > command line options as well.)
> 
>   Yes, that's right.
> 
> | > However, we also need to cover dynamically-added devices. Aborting seems 
> | > very bad there, just failing to add the device seems like what we'd want.
> | 
> | Yep, aborting is simply not an option for the inner code. It all has to 
> | propagate to a proper Error **errp object. The ultimate entry-point at the 
> | CLI vs QMP then decides whether to turn the error into an abort or feed back 
> | to the client app.
> 
>   True, handling dynamic devices is tricky.
> 
> Though it seems kind of uniform workflow to check for '--security' flag at 
> options parsing OR while handling dynamic devices at run time; It is a huge 
> task to cover all options/use-cases for all QEMU emulators across various 
> architectures.

Yes, I mentioned earlier in the thread that doing this security check at
runtime is going to be a huge amount of work, because it will need to be
wired up across a wide range of subsystems and APIS and implemnetations
in the QEMU codebase.

I don't think option parsing time will be the place you want a check
at all. You need to parse the --security flag, but once that's done
I think everything else needs to be done at time of object creation,
not config parsing. That ensures the check is present in all possible
codepaths that lead to the functionality being used.

> * If this approach is reasonable, I'll try to make an initial patch towards 
>   it.
> 
> * We'd still need to figure out similar way for compile time option, to 
>   exclude building insecure features at build time.

My suggestion is to do compile time stuff first, as that ought to be a
simpler problem. Having said that, if Paolo's work on meson is likely
to arrive any time soon, then it might make sense to wait for that,
instead of implementing something for Make and then throwing it away
a release later and doing it from scratch in Meson.


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|



^ permalink raw reply	[flat|nested] 28+ messages in thread
* Re: [PATCH 1/1] MAINTAINERS: introduce cve or security quotient field
  2020-07-16  8:56   ` Dr. David Alan Gilbert
@ 2020-07-16  9:44     ` P J P
  2020-07-16 10:09       ` Daniel P. Berrangé
  0 siblings, 1 reply; 28+ messages in thread
From: P J P @ 2020-07-16  9:44 UTC (permalink / raw)
  To: Dr. David Alan Gilbert
  Cc: Kevin Wolf, Peter Maydell, Stefano Stabellini,
	Daniel P . Berrange, Michael S . Tsirkin, Christian Schoenebeck,
	Michael Roth, QEMU Developers, Greg Kurz, Stefan Hajnoczi,
	Paolo Bonzini

+-- On Thu, 16 Jul 2020, Dr. David Alan Gilbert wrote --+
| > +	C: CVE/Security/Trust Quotient
| > +	   H:High - Feature (or code) is meant to be safe and used by untrusted
| > +	            guests. So any potential security issue must be processed with
| > +	            due care and be considered as a CVE issue.
| > +	   L:Low  - Feature (or code) is not meant to be safe OR is experimental
| > +	            OR is used in trusted environments only OR is not well
| > +	            maintained. So any potential security issue can be processed
| > +	            and fixed as regular non-security bug. No need for a CVE.
| 
| That's a lot of OR's and it causes problems;
| ....

  Yes, I started with the MAINTAINERS file thinking at least some segregation 
would be a step forward than nothing.
 
| >  QMP
| >  M: Markus Armbruster <armbru@redhat.com>
| >  S: Supported
| > +C: Low
| >  F: monitor/monitor-internal.h
| >  F: monitor/qmp*
| >  F: monitor/misc.c
| 
| QMP is critical to many uses, so you wouldn't want to exclude it from a secure build;
| any security issue with it (e.g. misparsing an argument) would be very
| serious and would need to be looked at;

   No, High OR Low was not for excluding it from any build. It was merely an 
indication to a user to decide whether an issue should be treated as a CVE one 
or can be fixed as regular bug.

| but QMP is expected to be talking to another trusted endpoint.

  True; I set it to Low as QMP interface access is mostly given to privileged 
trusted users.


Thank you.
--
Prasad J Pandit / Red Hat Product Security Team
8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D



^ permalink raw reply	[flat|nested] 28+ messages in thread
* Re: [PATCH 1/1] MAINTAINERS: introduce cve or security quotient field
  2020-07-16  9:21                   ` P J P
  2020-07-16  9:39                     ` Daniel P. Berrangé
@ 2020-07-16  9:45                     ` Christian Schoenebeck
  2020-07-16 10:01                       ` Daniel P. Berrangé
  1 sibling, 1 reply; 28+ messages in thread
From: Christian Schoenebeck @ 2020-07-16  9:45 UTC (permalink / raw)
  To: qemu-devel
  Cc: P J P, Daniel P. Berrangé,
	Kevin Wolf, Peter Maydell, Stefano Stabellini,
	Michael S. Tsirkin, Cornelia Huck, Michael Roth, Greg Kurz,
	Stefan Hajnoczi, Paolo Bonzini, Philippe Mathieu-Daudé

On Donnerstag, 16. Juli 2020 11:21:55 CEST P J P wrote:
> +-- On Thu, 16 Jul 2020, Daniel P. Berrangé wrote --+
> 
> | > Failing to start (with a message that explains why) if one of the
> | > command
> | > line options is not covered by a specified security policy is not
> | > unreasonable (after all, we fail to start for other cases of
> | > incompatible
> | > command line options as well.)
> 
>   Yes, that's right.
> 
> | > However, we also need to cover dynamically-added devices. Aborting seems
> | > very bad there, just failing to add the device seems like what we'd
> | > want.
> | 
> | Yep, aborting is simply not an option for the inner code. It all has to
> | propagate to a proper Error **errp object. The ultimate entry-point at the
> | CLI vs QMP then decides whether to turn the error into an abort or feed
> | back to the client app.
> 
>   True, handling dynamic devices is tricky.
> 
> Though it seems kind of uniform workflow to check for '--security' flag at
> options parsing OR while handling dynamic devices at run time; It is a huge
> task to cover all options/use-cases for all QEMU emulators across various
> architectures.

My concern here is that just distinguishing between either 'low' or 'high' is 
a far too rough classification.

In our preceding communication regarding 9pfs, I made clear that a) we do care 
about security relevant 9pfs issues, and only b) the avarage use cases (as far 
we know) for 9pfs are above a certain trust level.

However b) does not imply 9pfs being 'unsafe', nor that we want users to 
refrain using it in a security relevant environment. So 9pfs would actually be 
somewhere in between.

Best regards,
Christian Schoenebeck




^ permalink raw reply	[flat|nested] 28+ messages in thread
* Re: [PATCH 1/1] MAINTAINERS: introduce cve or security quotient field
  2020-07-16  9:45                     ` Christian Schoenebeck
@ 2020-07-16 10:01                       ` Daniel P. Berrangé
  2020-07-16 12:22                         ` Christian Schoenebeck
  0 siblings, 1 reply; 28+ messages in thread
From: Daniel P. Berrangé @ 2020-07-16 10:01 UTC (permalink / raw)
  To: Christian Schoenebeck
  Cc: Kevin Wolf, Peter Maydell, Stefano Stabellini, Michael Roth,
	Michael S. Tsirkin, Cornelia Huck, qemu-devel, P J P, Greg Kurz,
	Stefan Hajnoczi, Paolo Bonzini, Philippe Mathieu-Daudé

On Thu, Jul 16, 2020 at 11:45:50AM +0200, Christian Schoenebeck wrote:
> On Donnerstag, 16. Juli 2020 11:21:55 CEST P J P wrote:
> > +-- On Thu, 16 Jul 2020, Daniel P. Berrangé wrote --+
> > 
> > | > Failing to start (with a message that explains why) if one of the
> > | > command
> > | > line options is not covered by a specified security policy is not
> > | > unreasonable (after all, we fail to start for other cases of
> > | > incompatible
> > | > command line options as well.)
> > 
> >   Yes, that's right.
> > 
> > | > However, we also need to cover dynamically-added devices. Aborting seems
> > | > very bad there, just failing to add the device seems like what we'd
> > | > want.
> > | 
> > | Yep, aborting is simply not an option for the inner code. It all has to
> > | propagate to a proper Error **errp object. The ultimate entry-point at the
> > | CLI vs QMP then decides whether to turn the error into an abort or feed
> > | back to the client app.
> > 
> >   True, handling dynamic devices is tricky.
> > 
> > Though it seems kind of uniform workflow to check for '--security' flag at
> > options parsing OR while handling dynamic devices at run time; It is a huge
> > task to cover all options/use-cases for all QEMU emulators across various
> > architectures.
> 
> My concern here is that just distinguishing between either 'low' or 'high' is 
> a far too rough classification.
> 
> In our preceding communication regarding 9pfs, I made clear that a) we do care 
> about security relevant 9pfs issues, and only b) the avarage use cases (as far 
> we know) for 9pfs are above a certain trust level.
> 
> However b) does not imply 9pfs being 'unsafe', nor that we want users to 
> refrain using it in a security relevant environment. So 9pfs would actually be 
> somewhere in between.

We shouldn't overthink this and invent many classification levels.

This is essentially about distinguishing code that is written with the
intent of protecting from a malicous guest, from code that assumes a
non-malicious guest. That is a pretty clear demarcation on when it is
reasonable to use any given feature in QEMU.

Within the set of code that is assuming a malicious guest, there are
still going to be varying levels of quality, and that is ok. We don't
need to express that programatically, the docs are still there to
describe the fine nuances of any given feature. We're just saying that
in general, this set of code is acceptable to use in combination with
a malicious guest, and if you find bugs we'll triage them as security
flaws.

9p is generally written from the POV of protecting against a malicious
guest, so it would be considered part of the high security set, and
flaws will be treated as CVEs. We don't need to be break it down into
any more detail than that.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|



^ permalink raw reply	[flat|nested] 28+ messages in thread
* Re: [PATCH 1/1] MAINTAINERS: introduce cve or security quotient field
  2020-07-16  9:44     ` P J P
@ 2020-07-16 10:09       ` Daniel P. Berrangé
  2020-07-16 10:43         ` Markus Armbruster
  0 siblings, 1 reply; 28+ messages in thread
From: Daniel P. Berrangé @ 2020-07-16 10:09 UTC (permalink / raw)
  To: P J P
  Cc: Kevin Wolf, Peter Maydell, Stefano Stabellini,
	Michael S . Tsirkin, QEMU Developers, Christian Schoenebeck,
	Dr. David Alan Gilbert, Michael Roth, Greg Kurz, Stefan Hajnoczi,
	Paolo Bonzini

On Thu, Jul 16, 2020 at 03:14:51PM +0530, P J P wrote:
> +-- On Thu, 16 Jul 2020, Dr. David Alan Gilbert wrote --+
> | > +	C: CVE/Security/Trust Quotient
> | > +	   H:High - Feature (or code) is meant to be safe and used by untrusted
> | > +	            guests. So any potential security issue must be processed with
> | > +	            due care and be considered as a CVE issue.
> | > +	   L:Low  - Feature (or code) is not meant to be safe OR is experimental
> | > +	            OR is used in trusted environments only OR is not well
> | > +	            maintained. So any potential security issue can be processed
> | > +	            and fixed as regular non-security bug. No need for a CVE.
> | 
> | That's a lot of OR's and it causes problems;
> | ....
> 
>   Yes, I started with the MAINTAINERS file thinking at least some segregation 
> would be a step forward than nothing.
>  
> | >  QMP
> | >  M: Markus Armbruster <armbru@redhat.com>
> | >  S: Supported
> | > +C: Low
> | >  F: monitor/monitor-internal.h
> | >  F: monitor/qmp*
> | >  F: monitor/misc.c
> | 
> | QMP is critical to many uses, so you wouldn't want to exclude it from a secure build;
> | any security issue with it (e.g. misparsing an argument) would be very
> | serious and would need to be looked at;
> 
>    No, High OR Low was not for excluding it from any build. It was merely an 
> indication to a user to decide whether an issue should be treated as a CVE one 
> or can be fixed as regular bug.
> 
> | but QMP is expected to be talking to another trusted endpoint.
> 
>   True; I set it to Low as QMP interface access is mostly given to privileged 
> trusted users.

It needs to consider that the classification will eventually be used to decide
what features are enabled at build time. If QMP is marked as "low" and someone
does a build "only high", then QMP won't get compiled, and thus QEMU will be
useless for mgmt apps.

Also bear in the mind the documented security classification is that approx
anything relevant for use with KVM based deployment is to be considered part
of the trusted code set, and anything that only makes sense for use with TCG
is part of the untrusted code set.

This implies that much general purpose common infrastructure in QEMU is
going to be part of the trusted code set. So that automatically includes
QMP.

NB, the build time classification won't be perfect, but that's largely
because we don't have sufficient granularity in what we build. For
example, although we only care about QMP, IIUC, we can't turn off HMP
at build time.  So we might consider HMP to be "low", despite the fact
that it is impossible to disable when building "only high features".

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|



^ permalink raw reply	[flat|nested] 28+ messages in thread
* Re: [PATCH 1/1] MAINTAINERS: introduce cve or security quotient field
  2020-07-16 10:09       ` Daniel P. Berrangé
@ 2020-07-16 10:43         ` Markus Armbruster
  0 siblings, 0 replies; 28+ messages in thread
From: Markus Armbruster @ 2020-07-16 10:43 UTC (permalink / raw)
  To: Daniel P. Berrangé
  Cc: Kevin Wolf, Peter Maydell, Stefano Stabellini, Michael Roth,
	Michael S . Tsirkin, Christian Schoenebeck, QEMU Developers,
	P J P, Greg Kurz, Stefan Hajnoczi, Paolo Bonzini,
	Dr. David Alan Gilbert

Daniel P. Berrangé <berrange@redhat.com> writes:

[...]
> NB, the build time classification won't be perfect, but that's largely
> because we don't have sufficient granularity in what we build. For
> example, although we only care about QMP, IIUC, we can't turn off HMP
> at build time.

It could be made compile-time optional.  Matter of coding.  But I doubt
it would buy us much.  Like QMP, it should only ever be exposed to
trusted parties.

>                 So we might consider HMP to be "low", despite the fact
> that it is impossible to disable when building "only high features".

I'm sure we could find more examples where the current granularity is
too coarse for a clean sorting into "low" and "high" buckets.



^ permalink raw reply	[flat|nested] 28+ messages in thread
* Re: [PATCH 1/1] MAINTAINERS: introduce cve or security quotient field
  2020-07-16 10:01                       ` Daniel P. Berrangé
@ 2020-07-16 12:22                         ` Christian Schoenebeck
  2020-07-16 12:54                           ` Daniel P. Berrangé
  0 siblings, 1 reply; 28+ messages in thread
From: Christian Schoenebeck @ 2020-07-16 12:22 UTC (permalink / raw)
  To: qemu-devel, Daniel P. Berrangé
  Cc: Kevin Wolf, Peter Maydell, Stefano Stabellini, Michael Roth,
	Michael S. Tsirkin, Cornelia Huck, P J P, Greg Kurz,
	Stefan Hajnoczi, Paolo Bonzini, Philippe Mathieu-Daudé

On Donnerstag, 16. Juli 2020 12:01:57 CEST Daniel P. Berrangé wrote:
> > My concern here is that just distinguishing between either 'low' or 'high'
> > is a far too rough classification.
> > 
> > In our preceding communication regarding 9pfs, I made clear that a) we do
> > care about security relevant 9pfs issues, and only b) the avarage use
> > cases (as far we know) for 9pfs are above a certain trust level.
> > 
> > However b) does not imply 9pfs being 'unsafe', nor that we want users to
> > refrain using it in a security relevant environment. So 9pfs would
> > actually be somewhere in between.
> 
> We shouldn't overthink this and invent many classification levels.
> 
> This is essentially about distinguishing code that is written with the
> intent of protecting from a malicous guest, from code that assumes a
> non-malicious guest. That is a pretty clear demarcation on when it is
> reasonable to use any given feature in QEMU.
> 
> Within the set of code that is assuming a malicious guest, there are
> still going to be varying levels of quality, and that is ok. We don't
> need to express that programatically, the docs are still there to
> describe the fine nuances of any given feature. We're just saying that
> in general, this set of code is acceptable to use in combination with
> a malicious guest, and if you find bugs we'll triage them as security
> flaws.

Yes, that would be a base consideration for any security classification. And 
it applies to 9pfs hence it would suggest 'high' for 9pfs, but ...

> 9p is generally written from the POV of protecting against a malicious
> guest, so it would be considered part of the high security set, and
> flaws will be treated as CVEs. We don't need to be break it down into
> any more detail than that.

... this is where it already differs from reality, as 9pfs security issues 
were both handled as CVEs as well as normal reports for years, which nobody 
objected.

So I wonder how helpful it would be trying to either put 9pfs into either 
'high' or 'low', because another observed problematic with 9pfs is that the 
degree of participation is so low, that if you try to impose certain formal 
minimum requirements to contributors, you usually never hear from them again.

And BTW Prasad actually suggested the opposite classification: 

> @@ -1761,6 +1927,7 @@ virtio-9p
> 
>  M: Greg Kurz <groug@kaod.org>
>  M: Christian Schoenebeck <qemu_oss@crudebyte.com>
>  S: Odd Fixes
> 
> +C: Low
> 
>  F: hw/9pfs/
>  X: hw/9pfs/xen-9p*
>  F: fsdev/

Even though we discussed this issue with him in detail before, which probably 
shows that a simple binary security classification is too coarse and too 
ambiguous.

Best regards,
Christian Schoenebeck




^ permalink raw reply	[flat|nested] 28+ messages in thread
* Re: [PATCH 1/1] MAINTAINERS: introduce cve or security quotient field
  2020-07-16 12:22                         ` Christian Schoenebeck
@ 2020-07-16 12:54                           ` Daniel P. Berrangé
  0 siblings, 0 replies; 28+ messages in thread
From: Daniel P. Berrangé @ 2020-07-16 12:54 UTC (permalink / raw)
  To: Christian Schoenebeck
  Cc: Kevin Wolf, Peter Maydell, Stefano Stabellini,
	Michael S. Tsirkin, Cornelia Huck, qemu-devel, Michael Roth,
	Greg Kurz, Stefan Hajnoczi, Paolo Bonzini, P J P,
	Philippe Mathieu-Daudé

On Thu, Jul 16, 2020 at 02:22:14PM +0200, Christian Schoenebeck wrote:
> On Donnerstag, 16. Juli 2020 12:01:57 CEST Daniel P. Berrangé wrote:
> > > My concern here is that just distinguishing between either 'low' or 'high'
> > > is a far too rough classification.
> > > 
> > > In our preceding communication regarding 9pfs, I made clear that a) we do
> > > care about security relevant 9pfs issues, and only b) the avarage use
> > > cases (as far we know) for 9pfs are above a certain trust level.
> > > 
> > > However b) does not imply 9pfs being 'unsafe', nor that we want users to
> > > refrain using it in a security relevant environment. So 9pfs would
> > > actually be somewhere in between.
> > 
> > We shouldn't overthink this and invent many classification levels.
> > 
> > This is essentially about distinguishing code that is written with the
> > intent of protecting from a malicous guest, from code that assumes a
> > non-malicious guest. That is a pretty clear demarcation on when it is
> > reasonable to use any given feature in QEMU.
> > 
> > Within the set of code that is assuming a malicious guest, there are
> > still going to be varying levels of quality, and that is ok. We don't
> > need to express that programatically, the docs are still there to
> > describe the fine nuances of any given feature. We're just saying that
> > in general, this set of code is acceptable to use in combination with
> > a malicious guest, and if you find bugs we'll triage them as security
> > flaws.
> 
> Yes, that would be a base consideration for any security classification. And 
> it applies to 9pfs hence it would suggest 'high' for 9pfs, but ...
> 
> > 9p is generally written from the POV of protecting against a malicious
> > guest, so it would be considered part of the high security set, and
> > flaws will be treated as CVEs. We don't need to be break it down into
> > any more detail than that.
> 
> ... this is where it already differs from reality, as 9pfs security issues 
> were both handled as CVEs as well as normal reports for years, which nobody 
> objected.

Even if something is classified as "high", we still have the freedom to
decide whether each specific issue is worthy of a CVE or not.

> So I wonder how helpful it would be trying to either put 9pfs into either 
> 'high' or 'low', because another observed problematic with 9pfs is that the 
> degree of participation is so low, that if you try to impose certain formal 
> minimum requirements to contributors, you usually never hear from them again.
> 
> And BTW Prasad actually suggested the opposite classification: 

I don't personally mind whether 9p is classified high or low. It is really
upto the maintainers to decide which classification best fits. I'm just
saying that I think the simple binary choice is sufficient for our needs.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|



^ permalink raw reply	[flat|nested] 28+ messages in thread
end of thread, other threads:[~2020-07-16 12:55 UTC | newest]

Thread overview: 28+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-07-14  8:36 [PATCH 0/1] MAINTAINERS: add security quotient field P J P
2020-07-14  8:36 ` [PATCH 1/1] MAINTAINERS: introduce cve or " P J P
2020-07-14  9:42   ` Peter Maydell
2020-07-14  9:52     ` Daniel P. Berrangé
2020-07-14 10:12       ` Michael S. Tsirkin
2020-07-14 10:22         ` Peter Maydell
2020-07-14 11:02           ` Michael S. Tsirkin
2020-07-14 13:10             ` P J P
2020-07-16  6:55               ` Cornelia Huck
2020-07-16  8:36                 ` Daniel P. Berrangé
2020-07-16  9:21                   ` P J P
2020-07-16  9:39                     ` Daniel P. Berrangé
2020-07-16  9:45                     ` Christian Schoenebeck
2020-07-16 10:01                       ` Daniel P. Berrangé
2020-07-16 12:22                         ` Christian Schoenebeck
2020-07-16 12:54                           ` Daniel P. Berrangé
2020-07-14 13:30             ` Daniel P. Berrangé
2020-07-14 13:48               ` Kevin Wolf
2020-07-14 13:56                 ` Thomas Huth
2020-07-14 15:04                   ` Christian Schoenebeck
2020-07-14 14:02                 ` Daniel P. Berrangé
2020-07-14 10:18   ` Philippe Mathieu-Daudé
2020-07-14 11:51   ` Cornelia Huck
2020-07-16  8:56   ` Dr. David Alan Gilbert
2020-07-16  9:44     ` P J P
2020-07-16 10:09       ` Daniel P. Berrangé
2020-07-16 10:43         ` Markus Armbruster
2020-07-14  9:46 ` [PATCH 0/1] MAINTAINERS: add " Michael S. Tsirkin

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.