qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Daniel P. Berrange" <berrange@redhat.com>
To: Cornelia Huck <cohuck@redhat.com>
Cc: Stefan Weil <sw@weilnetz.de>, QEMU Developer <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] German BSI analysed security of KVM / QEMU
Date: Fri, 13 Oct 2017 10:44:00 +0100	[thread overview]
Message-ID: <20171013094400.GD20515@redhat.com> (raw)
In-Reply-To: <20171013113708.2dd02a17.cohuck@redhat.com>

On Fri, Oct 13, 2017 at 11:37:08AM +0200, Cornelia Huck wrote:
> On Fri, 13 Oct 2017 11:10:05 +0200
> Stefan Weil <sw@weilnetz.de> wrote:
> 
> > Hi,
> > 
> > the German Bundesamt für Sicherheit in der Informationstechnik
> > (Federal Office for Information Security) published a study on
> > the security of KVM and QEMU:
> > 
> > https://www.bsi.bund.de/DE/Publikationen/Studien/Sicherheitsanalyse_KVM/sicherheitsanalyse_kvm.html
> > 
> > (article only available in German)
> 
> Thanks for posting this!
> 
> I only looked at the conclusion for now. Some interesting points:
> 
> - They state that QEMU's source code is well structured, readable and
>   maintainable. I wonder what kind of source code they usually deal
>   with ;)

Most closed source apps are worse than even badly structured open
source code IME ;-)

> - Most problems noted seemed to be related to signed<->unsigned
>   conversions, but none were found to be exploitable.
> - They liked hardening via stack protection, NX, and ASLR, as well as
>   the mechanisms used by libvirt.
> - They generally seemed to be happy with QEMU being deployed via
>   libvirt.
> - Restrictions imposed via KVM (guest access to some CPU registers)
>   scored positive points. They did not like that Hyper-V and PMU were
>   not deconfigurable.
> - Lack of support for encryption/signing of network-based images was
>   criticized. They ended up using Ceph and GlusterFS, which they were
>   reasonably happy with.

Hopefully the 'luks' driver (which can be layered over any block backend
including network ones), and the TLS support for NBD would be considered
to address this last point to some degree. At least from the encryption
side.

Signing of disk images is impractical as it would imply having to download
the entire image contents to validate signature, rather defeating the point
of having a network based image. But perhaps this is lost in translation
and they mean something else by "signing of images" ?

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 :|

  reply	other threads:[~2017-10-13  9:44 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-13  9:10 [Qemu-devel] German BSI analysed security of KVM / QEMU Stefan Weil
2017-10-13  9:37 ` Cornelia Huck
2017-10-13  9:44   ` Daniel P. Berrange [this message]
2017-10-13  9:53     ` Cornelia Huck
2017-10-16 13:22     ` Kevin Wolf
2017-10-16 13:38       ` Daniel P. Berrange
2017-10-16 13:47         ` [Qemu-devel] [Qemu-block] " Alberto Garcia
2017-10-16 15:24         ` [Qemu-devel] " Kevin Wolf
2017-10-13 10:30   ` Stefan Weil

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=20171013094400.GD20515@redhat.com \
    --to=berrange@redhat.com \
    --cc=cohuck@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=sw@weilnetz.de \
    /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).