qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] German BSI analysed security of KVM / QEMU


From: Daniel P. Berrange
Subject: Re: [Qemu-devel] German BSI analysed security of KVM / QEMU
Date: Fri, 13 Oct 2017 10:44:00 +0100
User-agent: Mutt/1.9.0 (2017-09-02)

On Fri, Oct 13, 2017 at 11:37:08AM +0200, Cornelia Huck wrote:
> On Fri, 13 Oct 2017 11:10:05 +0200
> Stefan Weil <address@hidden> 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 via email to

[Prev in Thread] Current Thread [Next in Thread]