On 28 October 2018 at 05:43, Markus Armbruster <arm...@redhat.com> wrote: > Daniel P. Berrangé <berra...@redhat.com> writes: >> 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.
We've generally done it the other way around -- we define the small set of machines whose security boundary we care about (ie the ones we can run with KVM), and then classify the devices accordingly (mandatory in a machine where we care about the security boundary => we need to care about the security of the device; pluggable in a machine we care about => care; mandatory or pluggable in a machine we don't care about the security of => don't care about the device either). I think doing it that way fits (a) the way we've defined the boundary of our security policy as "with KVM" (b) the way users probably care more about machines rather than the specifics of which devices they happen to include and (c) the way there are fewer machines than devices. thanks -- PMM