Re: [Qemu-devel] Minutes of KVM Forum BoF on deprecating stuff
On 10/26/2018 10:22 AM, Daniel P. Berrangé wrote: > > 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. > > 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. > It would be really helpful to describe which devices receive which kind of support. At the highest tier of support, we offer some kind of guarantee: this device is secure (as far as we know), and will receive CVE patches promptly. At the next tier of support, we expect that the device works, but it may be best-effort. At the lowest tier, the devices are experimental and absolutely should not show up in a production environment. Of course, RHEL's configuration has made some assessments as to what's safe and what isn't -- but this information isn't reflected here in our upstream configuration. It would be nice to effectively convert everything over to qdev, make the support level a metadata construct, and even allow configurations like ./configure --enterprise-devices-only that disable the ability to load or interface with anything we don't promise support for. >> Topics we covered, reordered for readability: >> >> * Dropping features inconveniences their users. Keeping them impedes >> forward movement, and thus inconveniences other users. We need to >> engage with the tradeoffs. >> >> * The cost of keeping both old and new for a deprecation grace period >> (currently two releases) can be painfully high. Tradeoff again. >> However, there's rough consensus not to mess with the deprecation >> policy right now. >> >> * When something has been broken for the customary deprecation grace >> period, removing it without going through the deprecation process >> should be okay. >> >> * We may have to deprecate interfaces, but we may also have a need to >> deprecate guarantees interfaces provide. Worse when the guarantees >> are tacit. No good answers. Let's attack less thorny problems first. >> >> * One obvious class of candidates for removal is machines we don't know >> how to boot, or can't boot, say because we lack required firmware >> and/or OS. >> >> Of course, "can boot" should be an automated test. As a first step >> towards that, we should at least document how to boot each machine. >> We're going to ask machine maintainers to do that. >> >> * We need to communicate "you're using something that is deprecated". >> How? Right now, we print a deprecation message. Okay when humans use >> QEMU directly in a shell. However, when QEMU sits at the bottom of a >> software stack, the message will likely end up in a log file that is >> effectively write-only. >> >> - The one way to get people read log files is crashing their >> application. A command line option --future could make QEMU crash >> right after printing a deprecation message. This could help with >> finding use of deprecated features in a testing environment. >> >> - A less destructive way to grab people's attention is to make things >> run really, really slow: have QEMU go to sleep for a while after >> printing a deprecation message. >> >> - We can also pass the buck to the next layer up: emit a QMP event. >> >> Sadly, by the time the next layer connects to QMP, plenty of stuff >> already happened. We'd have to buffer deprecation events somehow. >> >> What would libvirt do with such an event? Log it, taint the domain, >> emit a (libvirt) event to pass it on to the next layer up. >> >> - A completely different idea is to have a configuratin linter. To >> support doing this at the libvirt level, QEMU could expose "is >> deprecated" in interface introspection. Feels
Re: [Qemu-devel] Minutes of KVM Forum BoF on deprecating stuff
> On 26 Oct 2018, at 16:03, 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. > > Topics we covered, reordered for readability: > > * Dropping features inconveniences their users. Keeping them impedes > forward movement, and thus inconveniences other users. We need to > engage with the tradeoffs. > > * The cost of keeping both old and new for a deprecation grace period > (currently two releases) can be painfully high. Tradeoff again. > However, there's rough consensus not to mess with the deprecation > policy right now. > > * When something has been broken for the customary deprecation grace > period, removing it without going through the deprecation process > should be okay. > > * We may have to deprecate interfaces, but we may also have a need to > deprecate guarantees interfaces provide. Worse when the guarantees > are tacit. No good answers. Let's attack less thorny problems first. > > * One obvious class of candidates for removal is machines we don't know > how to boot, or can't boot, say because we lack required firmware > and/or OS. > > Of course, "can boot" should be an automated test. As a first step > towards that, we should at least document how to boot each machine. > We're going to ask machine maintainers to do that. > > * We need to communicate "you're using something that is deprecated". > How? Right now, we print a deprecation message. Okay when humans use > QEMU directly in a shell. However, when QEMU sits at the bottom of a > software stack, the message will likely end up in a log file that is > effectively write-only. A reliable way to bubble up important notifications to the end user is not a problem specific to deprecation. You may also need it e.g. to report unsupported configurations (incl. for licensing reasons), reporting severe runtime errors, etc. > > - The one way to get people read log files is crashing their >application. A command line option --future could make QEMU crash >right after printing a deprecation message. This could help with >finding use of deprecated features in a testing environment. I would try to make it more general. Also, I think it should be obvious that it may cause a crash. Something like —crash=deprecated,unsupported,veryslow,asserts with —crash alone enabling all of them. Also, even if you have to monitor your log files, finding what you need there is not necessarily obvious. > > - A less destructive way to grab people's attention is to make things >run really, really slow: have QEMU go to sleep for a while after >printing a deprecation message. > > - We can also pass the buck to the next layer up: emit a QMP event. > >Sadly, by the time the next layer connects to QMP, plenty of stuff >already happened. We'd have to buffer deprecation events somehow. QM events are fine if libvirt is the consumer. But there are other outlets for notifications, ranging from the GNOME notification center all the way to Insights. How do we reach those? > >What would libvirt do with such an event? Log it, taint the domain, >emit a (libvirt) event to pass it on to the next layer up. > > - A completely different idea is to have a configuratin linter. To >support doing this at the libvirt level, QEMU could expose "is >deprecated" in interface introspection. Feels feasible for QMP, >where we already have sufficiently expressive introspection. For >CLI, we'd first have to provide that (but we want that anyway). > > - We might also want to dispay deprecation messages in QEMU's GUI >somehow, or on serial consoles.
Re: [Qemu-devel] Minutes of KVM Forum BoF on deprecating stuff
On 28 October 2018 at 05:43, Markus Armbruster wrote: > Daniel P. Berrangé 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
Re: [Qemu-devel] Minutes of KVM Forum BoF on deprecating stuff
Daniel P. Berrangé 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.
Re: [Qemu-devel] Minutes of KVM Forum BoF on deprecating stuff
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. 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. > Topics we covered, reordered for readability: > > * Dropping features inconveniences their users. Keeping them impedes > forward movement, and thus inconveniences other users. We need to > engage with the tradeoffs. > > * The cost of keeping both old and new for a deprecation grace period > (currently two releases) can be painfully high. Tradeoff again. > However, there's rough consensus not to mess with the deprecation > policy right now. > > * When something has been broken for the customary deprecation grace > period, removing it without going through the deprecation process > should be okay. > > * We may have to deprecate interfaces, but we may also have a need to > deprecate guarantees interfaces provide. Worse when the guarantees > are tacit. No good answers. Let's attack less thorny problems first. > > * One obvious class of candidates for removal is machines we don't know > how to boot, or can't boot, say because we lack required firmware > and/or OS. > > Of course, "can boot" should be an automated test. As a first step > towards that, we should at least document how to boot each machine. > We're going to ask machine maintainers to do that. > > * We need to communicate "you're using something that is deprecated". > How? Right now, we print a deprecation message. Okay when humans use > QEMU directly in a shell. However, when QEMU sits at the bottom of a > software stack, the message will likely end up in a log file that is > effectively write-only. > > - The one way to get people read log files is crashing their > application. A command line option --future could make QEMU crash > right after printing a deprecation message. This could help with > finding use of deprecated features in a testing environment. > > - A less destructive way to grab people's attention is to make things > run really, really slow: have QEMU go to sleep for a while after > printing a deprecation message. > > - We can also pass the buck to the next layer up: emit a QMP event. > > Sadly, by the time the next layer connects to QMP, plenty of stuff > already happened. We'd have to buffer deprecation events somehow. > > What would libvirt do with such an event? Log it, taint the domain, > emit a (libvirt) event to pass it on to the next layer up. > > - A completely different idea is to have a configuratin linter. To > support doing this at the libvirt level, QEMU could expose "is > deprecated" in interface introspection. Feels feasible for QMP, > where we already have sufficiently expressive introspection. For > CLI, we'd first have to provide that (but we want that anyway). > > - We might also want to dispay deprecation messages in QEMU's GUI > somehow, or on serial consoles. Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
[Qemu-devel] Minutes of KVM Forum BoF on deprecating stuff
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. Topics we covered, reordered for readability: * Dropping features inconveniences their users. Keeping them impedes forward movement, and thus inconveniences other users. We need to engage with the tradeoffs. * The cost of keeping both old and new for a deprecation grace period (currently two releases) can be painfully high. Tradeoff again. However, there's rough consensus not to mess with the deprecation policy right now. * When something has been broken for the customary deprecation grace period, removing it without going through the deprecation process should be okay. * We may have to deprecate interfaces, but we may also have a need to deprecate guarantees interfaces provide. Worse when the guarantees are tacit. No good answers. Let's attack less thorny problems first. * One obvious class of candidates for removal is machines we don't know how to boot, or can't boot, say because we lack required firmware and/or OS. Of course, "can boot" should be an automated test. As a first step towards that, we should at least document how to boot each machine. We're going to ask machine maintainers to do that. * We need to communicate "you're using something that is deprecated". How? Right now, we print a deprecation message. Okay when humans use QEMU directly in a shell. However, when QEMU sits at the bottom of a software stack, the message will likely end up in a log file that is effectively write-only. - The one way to get people read log files is crashing their application. A command line option --future could make QEMU crash right after printing a deprecation message. This could help with finding use of deprecated features in a testing environment. - A less destructive way to grab people's attention is to make things run really, really slow: have QEMU go to sleep for a while after printing a deprecation message. - We can also pass the buck to the next layer up: emit a QMP event. Sadly, by the time the next layer connects to QMP, plenty of stuff already happened. We'd have to buffer deprecation events somehow. What would libvirt do with such an event? Log it, taint the domain, emit a (libvirt) event to pass it on to the next layer up. - A completely different idea is to have a configuratin linter. To support doing this at the libvirt level, QEMU could expose "is deprecated" in interface introspection. Feels feasible for QMP, where we already have sufficiently expressive introspection. For CLI, we'd first have to provide that (but we want that anyway). - We might also want to dispay deprecation messages in QEMU's GUI somehow, or on serial consoles.
