Track number of dispVMs opened by user

[redshiftzero]

there is a limitation to how many documents a user can have open at one time due to finite RAM (we should do some benchmarking to determine RAM usage for VMs using grsec kernels to get the number of VMs we should allow the user to open).

we should track the number of dispVMs opened by the user in the client in the database. if the user attempts to open a VM when we are at the VM limit of the device, we should stop the user, and say something like: "due to system constraints, please close some documents prior to opening this one".

we also need a way to track when a user closes a dispVM. we might be able to do this via sending messages from the dispVM back to the sd-svs AppVM using a feedback mechanism as described in freedomofpress/securedrop-workstation#46 (note that was marked as blocked due to an upstream issue).

note: there are security implications to allowing communication from the dispVM (where random files are open) back to the sd-svs AppVM (which is a vault VM where the rest of the documents are stored), so we should design this carefully.

the maximum number of allowable dispVMs should (eventually) be based on the specifications of the device, i.e. what if a news org buys a laptop with 32 GB of RAM because they want to open a ton of documents? this can potentially be something we have admins set.

[redshiftzero]

this is dependent on: #20

[redshiftzero]

note that there is a bug in repeated qrexec calls from a disposable VM to the AppVM that created it, see: freedomofpress/securedrop-workstation#46 (the person implementing this ticket may hit that bug since the VMs in which documents are opened are disposable)

[eloquence]

Making a note that we need UX for this, will likely be considered for beta.

[ninavizz]

^ where does "will likely be considered for beta" stand, today? I don't feel it's a high priority for the Pilot, but I certainly won't argue against it. I'd rather have read/unread in, first.

[redshiftzero]

oh yeah we should move this off the beta milestone (we can see how much of a pain point the dispVM management is during the pilot)

[deeplow]

@redshiftzero I took a little look at this.

It seems that the open-in-dvm.desktop calls /usr/bin/qvm-open-in-vm '@dispvm:sd-svs-disp' %f which is blocked until the dispvm is closed so we can use this to detect when the VM opens and closes.

Making a wrapper for that passes on the information to securedrop-client could be a fix.

I'm currently taking a look freedomofpress/securedrop-workstation#333 which if implemented would have implications on the way to make this.

[eloquence]

Discussed in backlog review today. Erik will do a little bit more follow-up with pilot participants, but so far, launching too many dispVMs has not been an issue for pilot users, as far as we know. There may also be useful upstream improvements that we can suggest to make memory pressure more understandable for the user.