Agreed.
* The untrusted thread would be restricted by seccomp mode 1 and
would contain the device emulation code.
I think the best strategy would allow for a device to run either in the
untrusted thread or the trusted thread. This makes performance testing a
bit easier and it also makes development a bit more natural.
When you refer to the device running in the trusted thread, are you
talking
about the case where you run QEMU without sandboxing support? I think
we would
ideally like to add this new support such that if it is not enabled,
QEMU will
still run as a single process and decomposition wouldn't occur.
* The trusted helper thread would run beside the untrusted thread,
enabling the untrusted thread to make syscalls beyond read(),
write(), exit(), and sigreturn().
I assume you mean process, not thread BTW?
I do mean thread. When making calls on behalf of the seccomp'd thread,
I think
there will be syscalls that must be called from the same address
space. That's
where the the trusted helper thread would come into play.
* IPC communication mechanisms:
* An IPC mechanism will be required to enable communication between
untrusted and trusted threads.
* An IPC mechanism will also be required to enable communication
between the main QEMU process and device processes.
IPC is easy. We have tons of infrastructure in QEMU for IPC (virtio,
QMP, etc.). Please don't reinvent the wheel here.
Ok
* The communication mechanisms must provide secure communication,
be low overhead (easy to generate, parse, and validate), and must
play well with sVirt/LSMs.
I don't see how sVirt/LSM fits into this but all of these requirements
are also true for the other big untrusted thread that we interact with
(the guest itself).
My view is that we should view the untrusted thread as an extension of
the guest and that the interfaces between the trusted thread and the
untrusted thread views it simply as another machine type that presents a
different (simpler) hardware abstraction.
Yes this makes sense. I think our biggest concern with IPC is that we
don't
introduce a TOCTTOU opportunity for a device to change call parameters
after
they've been checked and before the calls is made on behalf of the
sandboxed
thread. Shared memory that is writable by both untrusted/trusted
thread could
introduce this.