Work around Qubes' qrexec bug

[joshuathayer]

There's a bug in Qubes' qrexec infrastructure that stands in the way of our design for the "feedback" feature of SD-workstation. The bug has been reported to Qubes, along with a minimal reproducible example: QubesOS/qubes-issues#3318 (comment).

Briefly, the bug has to do with making repeated qrexec calls from a disposable VM back to the VM which created it. We use a custom qrexec service to send messages from the VMs involved in submission processing back to the sd-journalist VM (where the user kicks off the submission processing workflow). This allows us to indicate to the journalist that their documents are being processed, and alert them if errors occur.

Our disposable sd-decrypt VM is created by sd-journalist to handle submission decryption. We want sd-decrypt to report back to sd-journalist using our qrexec at a few points in the decryption process. However, the bug causes sd-decrypt to shut down immediately after the first qrexec call, so the rest of the submission processing fails silently.

Marek acknowledged the bug and gave some pointers about where to start fixing it, but it does not seem to be much on the Qubes' developers radar (not surprising, considering the number of more visible bugs in the push to release Qubes 4, etc). Rather than spend lots of our own resources trying to fix the issue, we decided to work around it for now so we can unblock our progress on the workstation product. We can revisit this bug and our workaround when sd-workstation is farther along, with hopes that by that time Qubes is more stable and this bug will easier to address.

For the time being, my workaround is to use a non-disposable VM for sd-decrypt. This seems to work fine: multiple qrexec calls back to sd-journalist complete without issue, and the full decryption process works great. Of course the security afforded by using a disposable VM is lost.

A further enhancement would be to try to emulate a disposable VM by qvm-removeing sd-journalist after every use, and qvm-createing it as part of submission processing. This might prove to be a bit harder, since those commands are used only in dom0 but our processing only touches AppVMs. There may be a way to use the new admin API in Qubes 4 to build and destroy VMs from non-dom0 VMs, though that will require more investigation.

I'll have a PR out shortly which implements the first workaround. We should keep an eye on the Qubes issue, and periodically try the example I lay out there in case the problem is fixed as a side-effect of some other change in Qubes.

[conorsch]

Given that we've nixed the sd-decrypt VM (#121), the original issue here may be moot. Before closing, however, @redshiftzero: are there additional areas in which handling feedback from DisposableVMs is relevant? Specifically concerned about post-client-code integration, i.e. once #138 is resolved.

[redshiftzero]

this same bug is relevant to freedomofpress/securedrop-client#52, but we can close the ticket in this workstation repo since it's not needed for submission processing. I'll just provide a quick summary over in the client repo so the person implementing freedomofpress/securedrop-client#52 knows about this bug