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 <m...@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
