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 <stefa...@gmail.com> 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
