All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cornelia Huck <cohuck@redhat.com>
To: P J P <ppandit@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
	Peter Maydell <peter.maydell@linaro.org>,
	Stefano Stabellini <sstabellini@kernel.org>,
	"Daniel P . Berrange" <berrange@redhat.com>,
	Prasad J Pandit <pjp@fedoraproject.org>,
	"Michael S . Tsirkin" <mst@redhat.com>,
	Christian Schoenebeck <qemu_oss@crudebyte.com>,
	Michael Roth <mdroth@linux.vnet.ibm.com>,
	QEMU Developers <qemu-devel@nongnu.org>,
	Greg Kurz <groug@kaod.org>, Stefan Hajnoczi <stefanha@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [PATCH 1/1] MAINTAINERS: introduce cve or security quotient field
Date: Tue, 14 Jul 2020 13:51:55 +0200	[thread overview]
Message-ID: <20200714135155.114f1a4f.cohuck@redhat.com> (raw)
In-Reply-To: <20200714083631.888605-2-ppandit@redhat.com>

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]



  parent reply	other threads:[~2020-07-14 11:53 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200714135155.114f1a4f.cohuck@redhat.com \
    --to=cohuck@redhat.com \
    --cc=berrange@redhat.com \
    --cc=groug@kaod.org \
    --cc=kwolf@redhat.com \
    --cc=mdroth@linux.vnet.ibm.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=pjp@fedoraproject.org \
    --cc=ppandit@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu_oss@crudebyte.com \
    --cc=sstabellini@kernel.org \
    --cc=stefanha@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.