All of lore.kernel.org
 help / color / mirror / Atom feed
From: Markus Armbruster <armbru@redhat.com>
To: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: Laurent Vivier <lvivier@redhat.com>,
	Pino Toscano <ptoscano@redhat.com>,
	Peter Krempa <pkrempa@redhat.com>,
	Alberto Garcia <berto@igalia.com>,
	Eduardo Habkost <ehabkost@redhat.com>,
	Christophe de Dinechin <cdupontd@redhat.com>,
	qemu-devel@nongnu.org, Laine Stump <laine@redhat.com>,
	Thomas Huth <thuth@redhat.com>,
	Andrea Bolognani <abologna@redhat.com>
Subject: Re: [Qemu-devel] Minutes of KVM Forum BoF on deprecating stuff
Date: Sun, 28 Oct 2018 06:43:44 +0100	[thread overview]
Message-ID: <87d0ruiq27.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <20181026142216.GB493@redhat.com> ("Daniel P. Berrangé"'s message of "Fri, 26 Oct 2018 15:22:16 +0100")

Daniel P. Berrangé <berrange@redhat.com> 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	other threads:[~2018-10-28  5:43 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-26 14:03 [Qemu-devel] Minutes of KVM Forum BoF on deprecating stuff Markus Armbruster
2018-10-26 14:22 ` Daniel P. Berrangé
2018-10-28  5:43   ` Markus Armbruster [this message]
2018-10-28 14:50     ` Peter Maydell
2018-10-29 20:14   ` John Snow
2018-10-29 11:38 ` Christophe de Dinechin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87d0ruiq27.fsf@dusky.pond.sub.org \
    --to=armbru@redhat.com \
    --cc=abologna@redhat.com \
    --cc=berrange@redhat.com \
    --cc=berto@igalia.com \
    --cc=cdupontd@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=laine@redhat.com \
    --cc=lvivier@redhat.com \
    --cc=pkrempa@redhat.com \
    --cc=ptoscano@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=thuth@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.