On 12/7/20 3:33 PM, Marek Marczykowski-Górecki wrote: > [moving to qubes-devel, to keep qubes-issues on topic] > > On Mon, Dec 07, 2020 at 09:50:01AM -0800, Demi Marie Obenour wrote: >> There are other improvements I can think of: > >> - Avoid spawning a `qrexec-client` process for each call. > > Yes, this is in fact the very next improvement to qrexec I'd like to see > (when we get to next round of qrexec improvements). Specifically: > > When qrexec-daemon receive call request from qrexec-agent, it should > connect to qrexec-policy-daemon (like it does now) and based on the > response, connect to the other qrexec-daemon (of the target domain) and > negotiate connection parameters. Avoid having qrexec-policy-daemon > spawning `qrexec-client` for this purpose. > But if the call target is dom0, still spawn a separate process (can be > existing `qrexec-client`). Similarly, when making a call from dom0, use > `qrexec-client`. > > The motivation for this approach is cleanup of responsibilities: > - qrexec-policy-* should be about policy evaluation, disentangled from > connection setup > - qrexec-daemon should be about connection coordination (control > packets, optimized for low latency), but not data path (optimized for > high throughput); this is because I fear some optimizations we could > make in one part may increase complexity of the other to preserve > performance requirements > - qrexec-client - data proxy (vchan <-> pipe/socket) for service calls > originating/targeting dom0 > > It isn't clear to me whether we need such control/data split on the VM > side, since there is significantly less control flow processing (no > interaction with policy, or other's VMs instances).
Agreed. The data path should be extremely simple and fast.
>> - Handle all requests inside a single agent process, rather than forking a
>> new process per connection.
>
> Just `fork` is relatively cheap in Linux, so I'd first carefully
> evaluate what we would gain here.
Indeed it is, but some applications (such as Qubes Manager) may make
hundreds of qrexec calls, so the cost can add up. This is probably
not the lowest-hanging fruit, though.
> But, there is another place that could use an improvement: avoid the
> requirement of spawning new `qrexec-client-vm` process to make each call.
> This could be done either by implementing `qrexec-client-vm`
> functionality as a library that could be used from within arbitrary
> application (IMO quite tricky, especially if such application has some
> event loop we'd need to integrate with), or by qrexec-agent exposing a
> socket where data could be exchanged directly (vchan connection would be
> handled on the agent side, not client side like right now). The latter
> one would look like SOCKS-like connection from the outside: simple
> header for qrexec call metadata (service, target) and then just data
> stream. Perhaps this could be even SOCKS(5?) protocol directly, to
> enable using existing client implementations.
A qrexec library would indeed be awesome. While having `qrexec-agent`
expose a socket would work, it won’t be able to be as fast, due
to requiring extra copies. However, it does have the advantage that
only the agent needs to be able to make Xen ioctls. Perhaps we could
use shared memory and SCM_RIGHTS?
The best way to integrate with event loops is probably to expose
a file descriptor that can be polled. In the future, we might
want a kernel-mode vchan driver, which could simplify matters
quite a bit. On Windows, I am honestly not certain how best to
integrate with event loops, although I believe the undocumented
Nt{Create,Associate,Cancel}WaitCompletionPacket syscalls might help.
Sincerely,
Demi
--
You received this message because you are subscribed to the Google Groups
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-devel/b2023a05-8b9d-9c5c-feb3-6a33fd17da51%40invisiblethingslab.com.
OpenPGP_0xB288B55FFF9C22C1.asc
Description: application/pgp-keys
OpenPGP_0xB288B55FFF9C22C1.asc
Description: application/pgp-keys
OpenPGP_signature
Description: OpenPGP digital signature
