On Wed, Sep 30, 2015 at 11:53:50AM +0100, Peter Maydell wrote: > On 30 September 2015 at 09:14, Dr. David Alan Gilbert > <dgilb...@redhat.com> wrote: > > * Markus Armbruster (arm...@redhat.com) wrote: > >> In my opinion, QEMU should leave them to separate GUI shells, because > >> doing everything in QEMU distracts from our core mission and we don't > >> have GUI expertise[*]. One more point: building in the GUI is > >> problematic when you don't trust the guest, because then you really want > >> to run QEMU with least privileges. > > > > Given that we have a built in GUI then I can see people wanting to expand > > it. > > Right, but where do you draw the line? We clearly don't have the > active maintainer and review capacity to do anything serious with > "ui/" (MAINTAINERS lists everything except SPICE as Odd Fixes). > > This is why I tend to agree with Markus' opinion here: we should > provide enough graphical UI to make raw QEMU minimally usable, > and leave further user-friendliness to other projects which have > more direct interest in that. > > If we had more regular contributors who were actively interested > in improving our UI layer my opinion might be different.
Even if we had more contributors interested in that, I still think that we should not do it, because building a UI into QEMU is a fundamentally bad design / architecture. QEMU is a security sensitive component and we want to know the boundaries of what a guest exploit can achieve - including a GUI massively expands the attack surface making it more or less impossible to confine any QEMU exploit, even with tools like SELinux/AppArmour, because you have to allow use of the desktop protocol at which point you can just talk to a separate app to perform the exploit. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|