On Tue, 14 Jul 2020 at 09:40, P J P <ppan...@redhat.com> wrote: > > From: Prasad J Pandit <p...@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.mayd...@linaro.org> > L: qemu-...@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.ben...@linaro.org> Something in your patch workflow is mangling UTF-8 characters, incidentally. thanks -- PMM
