Hey there,
After disappearing and thinking for a while about how to have some kind of support for GNU/Linux sandboxes with seamless integration to the window manager. I've thought a lot about how the Qubes approach does it using shared memory and Xorg messages but this doesn't work over the network, so I'm starting to wonder if it'd be better to just use something like Xpra. I'm not sure how big the TCB of it is versus just passing X messages, but it shouldn't really be that bad if you only give it access to files shared with the sandboxed system, meaning it'd be counterproductive to break in to Xpra.
Xpra also plans a Wayland port which might map well. Thoughts?
Jookia.
Hi Jookia,
On 05.09.2015 18:39, Jookia wrote:
After disappearing and thinking for a while about how to have some kind of support for GNU/Linux sandboxes with seamless integration to the window manager. I've thought a lot about how the Qubes approach does it using shared memory and Xorg messages but this doesn't work over the network, so I'm starting to wonder if it'd be better to just use something like Xpra. I'm not sure how big the TCB of it is versus just passing X messages, but it shouldn't really be that bad if you only give it access to files shared with the sandboxed system, meaning it'd be counterproductive to break in to Xpra.
Xpra also plans a Wayland port which might map well. Thoughts?
thanks to the pointer to the Xpra project. I was not aware of it. It looks very interesting. My thoughts after a quick look at the project's Wikipedia page:
* The complexity of the client does not matter because we would instantiate one client per guest, don't we? The client can merely talk to the nitpicker GUI server but has no special privileges. It does not even interact with the network, disk, or other devices. Hence, from Genode's perspective, the client does not need to be trusted.
* The mechanism relies on the network as communication channel. This raises the question of how to connect the client with the server running in the guest. Should there be a dedicated virtual network for this purpose? If the guest uses networking (e.g., when running a browser), we seem to need special routing tweaks and set up the VM with two NICs. This is a bit inconvenient but certainly not a big issue.
* Compared to the Qubes approach, the use of Xpra involves copying the pixel data. One could argue that this copy affects the performance in a negative way. However, on my 5-years old machine, the memory throughput is > 3 GiB per second. Copying an entire full-HD frame with 1920x1080 at 32-bit color depth (circa 8 MiB of data) takes less than 3 milliseconds. In my opinion, these costs are acceptable for the gain in simplicity (compared to setting up shared memory between the application running in the guest and the nitpicker GUI server).
In short, I find the project very interesting. A port might also be useful for scenarios where a Genode system is used as a thin client.
Cheers Norman
On Tue, Sep 08, 2015 at 10:39:36AM +0200, Norman Feske wrote:
- The complexity of the client does not matter because we would instantiate one client per guest, don't we? The client can merely talk to the nitpicker GUI server but has no special privileges. It does not even interact with the network, disk, or other devices. Hence, from Genode's perspective, the client does not need to be trusted.
That's what I've figured. Thinking more about it, I suppose I'm coming at it from a GNU/Linux situation where you have to divide a system up in to containers and you'd have to trust the client in dom0. Securely reusing complex projects seems to be a great trait of Genode.
- The mechanism relies on the network as communication channel. This raises the question of how to connect the client with the server running in the guest. Should there be a dedicated virtual network for this purpose? If the guest uses networking (e.g., when running a browser), we seem to need special routing tweaks and set up the VM with two NICs. This is a bit inconvenient but certainly not a big issue.
I'd be interested in having a way to chain together Genode systems and share data, much like a distributed system. You could then have a network interface run in the client with Genode itself as a daemon. Perhaps overkill.
- Compared to the Qubes approach, the use of Xpra involves copying the pixel data. One could argue that this copy affects the performance in a negative way. However, on my 5-years old machine, the memory throughput is > 3 GiB per second. Copying an entire full-HD frame with 1920x1080 at 32-bit color depth (circa 8 MiB of data) takes less than 3 milliseconds. In my opinion, these costs are acceptable for the gain in simplicity (compared to setting up shared memory between the application running in the guest and the nitpicker GUI server).
I figured that too, though it also supports compression and remote OpenGL which could be something to look at in the future.
In short, I find the project very interesting. A port might also be useful for scenarios where a Genode system is used as a thin client.
Sounds like a plan then. When my interest piques up in to Genode again I might take a stab at it.
Cheers Norman
Cheers, Jookia.
-
Jookia -
Norman Feske