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

[Thomas Huth]

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

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