qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Peter Maydell <peter.maydell@linaro.org>
To: Markus Armbruster <armbru@redhat.com>
Cc: "Daniel P. Berrangé" <berrange@redhat.com>,
	"Laurent Vivier" <lvivier@redhat.com>,
	"Thomas Huth" <thuth@redhat.com>,
	"Peter Krempa" <pkrempa@redhat.com>,
	"Alberto Garcia" <berto@igalia.com>,
	"Eduardo Habkost" <ehabkost@redhat.com>,
	"QEMU Developers" <qemu-devel@nongnu.org>,
	"Christophe de Dinechin" <cdupontd@redhat.com>,
	"Pino Toscano" <ptoscano@redhat.com>,
	"Laine Stump" <laine@redhat.com>,
	"Andrea Bolognani" <abologna@redhat.com>
Subject: Re: [Qemu-devel] Minutes of KVM Forum BoF on deprecating stuff
Date: Sun, 28 Oct 2018 14:50:37 +0000	[thread overview]
Message-ID: <CAFEAcA905T8aYVgWfAvDM7W13rW1tUndQ9WSXSAbzVu3pcOQAg@mail.gmail.com> (raw)
In-Reply-To: <87d0ruiq27.fsf@dusky.pond.sub.org>

On 28 October 2018 at 05:43, Markus Armbruster <armbru@redhat.com> wrote:
> Daniel P. Berrangé <berrange@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

  reply	other threads:[~2018-10-28 14:51 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
2018-10-28 14:50     ` Peter Maydell [this message]
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=CAFEAcA905T8aYVgWfAvDM7W13rW1tUndQ9WSXSAbzVu3pcOQAg@mail.gmail.com \
    --to=peter.maydell@linaro.org \
    --cc=abologna@redhat.com \
    --cc=armbru@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).