qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Minutes of KVM Forum BoF on deprecating stuff


From: Markus Armbruster
Subject: Re: [Qemu-devel] Minutes of KVM Forum BoF on deprecating stuff
Date: Sun, 28 Oct 2018 06:43:44 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)

Daniel P. Berrangé <address@hidden> writes:

> On Fri, Oct 26, 2018 at 04:03:51PM +0200, Markus Armbruster wrote:
>> This is from my (imperfect) notes, corrections welcome.
>> 
>> Motivation: QEMU contains stuff of dubious value, which gets in the way
>> in various (sometimes painful and expensive) ways.
>>
>> Deprecation is the marking of an external interface as "we intend to
>> remove this, you should stop using it" (preferably with advice on what
>> to use instead).  We have a deprecation policy to guide us through this
>> process.
>
>
> Something I meant to bring up but forgot is about the classification
> of devices, especially with a view towards security. It is not directly
> about deprecation, but it is somewhat related as it is related  to the
> state of maintainence and quality level
>
> We've got alot of devices, but only a subset are written and maintained
> to a level where we'd consider them robust wrt malcious guests. Other
> devices are only suitable for friendly guest environments. We should
> clearly document which are the devices that we consider to provide
> a secure boundary to guests, so users can make suitably informed choices.
> I'd guess this means all virtio devices, and then few of the emulated
> devices that are commonly used & maintained in a KVM environment.

A machine whose mandatory devices don't all provide a security boundary
also doesn't provide one.  Thus, classification of devices leads to a
classification of machines.

> This would be useful for distros/vendors/users who wish to limit their
> potential attack surface once we have a KConfig system for fine grained
> disablement of features.

Yes.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]