Re: [PATCH 1/1] MAINTAINERS: introduce cve or security quotient field

[Kevin Wolf]

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