[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-arm] [Qemu-devel] [RFC v3] qapi: command category to stimulate
From: |
Stefan Hajnoczi |
Subject: |
Re: [Qemu-arm] [Qemu-devel] [RFC v3] qapi: command category to stimulate high-level machine devices |
Date: |
Fri, 8 Jun 2018 08:58:30 +0100 |
User-agent: |
Mutt/1.9.5 (2018-04-13) |
On Thu, Jun 07, 2018 at 11:33:07AM +0100, Daniel P. Berrangé wrote:
> On Thu, Jun 07, 2018 at 11:24:55AM +0100, Stefan Hajnoczi wrote:
> > On Mon, Jun 04, 2018 at 12:12:21PM +0200, Gerd Hoffmann wrote:
> > > On Mon, Jun 04, 2018 at 10:29:40AM +0100, Peter Maydell wrote:
> > > > On 4 June 2018 at 10:20, Stefan Hajnoczi <address@hidden> wrote:
> > > > > Many of these inputs/outputs can be tied to an external UI. A degree
> > > > > of
> > > > > timing precision is required so that the UI is responsive, although
> > > > > cycle-accurate timing is not what I'd expect from QMP.
> > > >
> > > > Would we also be able to tie them to an internal UI, ie
> > > > something that appears as another view in the GTK/etc
> > > > UI frontends we have?
> > >
> > > Should be doable too. Basically a display device, which isn't a *real*
> > > display but the UI. Could show a rendering of the board, simliar to how
> > > web emulation environments are doing it. LED status could be rendered
> > > directly to the board. A virtual mouse could map mouse clicks to button
> > > presses.
> > >
> > > Doing more complex input that way (say a slider for the temperature
> > > sensor) isn't going to work very well though ...
> > >
> > > Sensor input in general is pretty much unsupported in qemu.
> >
> > For the micro:bit we've been thinking of a WebSocket monitor interface.
> > This way a web UI can work with both local and remote QEMU instances.
> >
> > For security reasons, the WebSocket cannot be the regular QMP monitor.
>
> FWIW, add ability to use websockets protocol over chardevs is fairly
> easy. We already have a QIOChannelWebsock for the VNC server, so it
> is just a little work to wire it into the chardev.
Cool, good to know.
> If the -monitor / -qmp arg took a filename containing a whitelist of
> allowed monitor commands, you could indeed use the regular QMP monitor
> instead of writing something new.
Yes, this is exactly what we need.
> > A slimmed down monitor is required with a subset of QMP commands and
> > events. For example, users must not be able to migrate to an exec:
> > destination so we need to ban that command on the UI monitor :-).
>
> FWIW, you could use the "-sandbox spawn=off,elevateprivileges=off"
> arg to prevent ability of QEMU to fork/exec/setuid. Even if the
> monitor still allows it, it thus get blocked, albeit by immediately
> terminating the process.
True, but that's just one example of many. Another one is "pmemsave",
which writes to the host file system.
I think a whitelist is the way to go. It will allow us to secure the
monitor and expose it to untrusted UIs.
Stefan
signature.asc
Description: PGP signature
Re: [Qemu-arm] [RFC v3] qapi: command category to stimulate high-level machine devices, Gerd Hoffmann, 2018/06/04