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 <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?
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
