All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrange" <berrange@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: qemu-devel qemu-devel <qemu-devel@nongnu.org>,
	Markus Armbruster <armbru@redhat.com>,
	Michael Roth <mdroth@linux.vnet.ibm.com>,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	Programmingkid <programmingkidx@gmail.com>,
	Peter Crosthwaite <crosthwaitepeter@gmail.com>
Subject: Re: [Qemu-devel] feature idea: allow user to run custom scripts
Date: Fri, 2 Oct 2015 13:33:24 +0100	[thread overview]
Message-ID: <20151002123324.GB10222@redhat.com> (raw)
In-Reply-To: <CAFEAcA-sFjbSfBRVDdLbpzK5NY97x2_QKGOT-RXdfvf8CgWWFw@mail.gmail.com>

On Wed, Sep 30, 2015 at 11:53:50AM +0100, Peter Maydell wrote:
> On 30 September 2015 at 09:14, Dr. David Alan Gilbert
> <dgilbert@redhat.com> wrote:
> > * Markus Armbruster (armbru@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 :|

  parent reply	other threads:[~2015-10-02 12:33 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-27  3:39 [Qemu-devel] feature idea: allow user to run custom scripts Programmingkid
2015-09-27 10:13 ` Peter Maydell
2015-09-27 18:53   ` Peter Crosthwaite
2015-09-28  1:49     ` Programmingkid
2015-09-28  2:30       ` Michael Roth
2015-09-28  3:10         ` Programmingkid
2015-09-28  7:29           ` Markus Armbruster
2015-09-28 19:43             ` Programmingkid
2015-09-28 19:44               ` Peter Maydell
2015-09-28 19:48                 ` Programmingkid
2015-09-29 13:11                 ` Dr. David Alan Gilbert
2015-09-29 13:17                   ` Programmingkid
2015-09-29 13:23                     ` Dr. David Alan Gilbert
2015-09-30  5:01                       ` Paolo Bonzini
2015-09-29 13:24                   ` Peter Maydell
2015-09-29 13:31                     ` Dr. David Alan Gilbert
2015-09-30  7:48                       ` Markus Armbruster
2015-09-30  8:14                         ` Dr. David Alan Gilbert
2015-09-30 10:53                           ` Peter Maydell
2015-09-30 14:23                             ` Programmingkid
2015-10-01 10:36                               ` Paolo Bonzini
2015-10-02 11:20                                 ` Kevin Wolf
2015-10-01  7:06                             ` Markus Armbruster
2015-10-02 12:33                             ` Daniel P. Berrange [this message]
2015-10-02 13:28                               ` Programmingkid
2015-10-01  6:55                           ` Markus Armbruster
2015-10-01  8:01                             ` Dr. David Alan Gilbert
2015-10-02 12:30                         ` Daniel P. Berrange
2015-10-02 13:33                           ` Dr. David Alan Gilbert
2015-10-02 14:28                             ` Daniel P. Berrange
2015-10-02 14:37                               ` Programmingkid
2015-10-02 16:21                                 ` Eric Blake
2015-10-02 17:57                                   ` Programmingkid

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=20151002123324.GB10222@redhat.com \
    --to=berrange@redhat.com \
    --cc=armbru@redhat.com \
    --cc=crosthwaitepeter@gmail.com \
    --cc=dgilbert@redhat.com \
    --cc=mdroth@linux.vnet.ibm.com \
    --cc=peter.maydell@linaro.org \
    --cc=programmingkidx@gmail.com \
    --cc=qemu-devel@nongnu.org \
    /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.