I got an idea to improve the user experience when dealing with disposable qubes. I rarely use them for one shot operation because starting them takes a while and it is absolutely boring to wait.
What if we had a mechanism to keep some disposable ready to use? You want to open a WWW link in a disposable? Here it is, ready to be used, then a new one would start immediately once you started to use one from the queue. The disposable could be paused so it does not use CPU, and the memory footprint would be limited because it would not be running anything big while waiting (given it uses memory balancing).
However, I am not sure how it would work on the back end side, it seems quite complicated to differentiate a waiting disposable from a running disposable. If we do not want users to use waiting disposables until an appropriate mechanism is triggered, they should be locked from users interaction. This new kind of qubes would make qubes tooling more complex GUI and CLI wise, not really good.
Any thoughts on that? Maybe I should just learn to wait a dozen seconds every time I need to use a disposable?
As for technicalities, I imagine it would be some property on a dispvm, and qubesd would keep a list of such dispvms to return when somebody requests a new dispvm (and at the same time, schedule starting another one in background to re-fill the pool).
This has been mooted before. Basically launch a “hidden” disposable, and
then use it on demand. Various people have tried implementing. The
issues are keeping track of the last created disposable - more difficult
now that we have multiple disposable templates. And that means that there
could be multiple unused disposables waiting to be used.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
I need 4-9 seconds to start dispVM depending on the overall load. I’m happy with it, I just changed my habits becoming more patient- security is of more significance to me than convenience of use.
I have tons of tasks that for each I start separate dispVM. In such a model, how this idea would’ve helped me?
In my idea, there would have been a pre-started disposable qube for each type of disposable. This feature would have been be opt-in so it would not pre-start every kind of disposable configured.
Thanks for clarification. Since my model assumes a lot of compartmentalization, that would not be feasible for me. Also, I don’t use always all the tasks. So, what I did was to create dom0 autostart dispVM entries for which I know will use for sure upon booting up machine.
Additional dispVM I need randomly I start when needed.
I don’t understand how it’s relevant here. You already start DispVMs in advance it seems, and it will be done automatically for you, so your time and effort will be saved.
While it’s not especially relevant to running services which connect to the web, I use a named disposable for viewing media files (images, videos, PDF files) offline. Creating a named disposable-media qube (and modifying qrexec policy to allow VMs to open media in that qube) allows you to have a semi-persistent running disposable qube at the ready. I set this up with a separate debian-minimal → debian-minimal-media-dvm → disposable-media template/dvm-template/named-disposable chain.
Obviously, this is less secure than using a discrete fresh dvm for each operation, but I find it to be an acceptable compromise between security and convenience. In my general use, if I open i.e. a PDF file I believe may be malicious, simply restarting the named disposable reverts the qube to a trusted state. Of course if the qube becomes compromised, any further media opened in the qube can be monitored by an attacker (though you could remediate this with a dom0 cronjob to perform qvm-shutdown --wait disposable-media && qvm-start disposable-media semi-frequently).
I would not recommend this approach for any web-based activities (my disposable-media qube is provided no network access - I would be skeptical of having a persistent network-enabled qube for untrusted tasks running in the background at all times), but for viewing media it has certainly saved me loads of time.
Or, maybe I don’t understand the idea. I use separate dispVM, created from separate dvm-templates, created from separate, specific templates. For example, accessing this site via tor browser, accessing my homebanking via specific browser dispVM, accessing Signal from separate dispVM. All of those are separate templates, created from minimals, containig only bare minimal packages for each task. How many of them would have to be pre-started so I could benefit of the idea?
Or people just use one dispVM (for example disp234) created from let’s say fedora-39-xfce(-dvm-template) for all of these tasks? I don’t get the concept of having one pre-running dispVM. What for?
I’ve thought about this, but the current solution seems a little hacky. For some no doubt, it is exactly what they want, but I don’t understand why they can’t just have autostarted named disposables?
It seems to me that what we really want is just disposables with a very fast boot time. If that’s the case, couldn’t we make an image of a started disposable to start disposables from? Kind of like suspend to disk or hibernate, except like a template? These qubes should start much faster with less overhead.
Please don’t expect this to be too polished. I just want to know how it sounds initially.
it is already working like that, a new disposable has its own dedicated LVM volumes and inherits everything from the disposable template
using named disposable works fine, but when you want to use “throwable” disposable for one shot operations like opening a web link, waiting for 5-15 seconds depending on your computer every time is really annoying.
But yes, ideally people just want disposable without startup time (under a second would be nice IMO)
So the disposable that is started isn’t booted like a powered-off machine, but booted like restoring a suspended/hibernated machine?
(Forgive me; I’m not familiar with the exact interworkings of power management, but it is my understanding that one of those takes the current state of a running machine, saves it to disk, and completely powers off. Then, upon turning the machine on, instead of booting, it mounts the saved state back to running state in the RAM and FS.)
What I’m proposing is the latter, by saving the state of a qube that has just been booted, and restoring that. That (if it works) would remove the CPU/RAM requirement of pre-started qubes, while only adding a minimal disk space requirement. Is that possible?
My understanding is the following. By default there is only one default Disposable. It doesn’t mean that you will have to only use that one. Ideally, you choose which Disposables are started in advance and reside in RAM, and next time you call them they appear instantly. In the worst case (until the best case gets implemented), only default Disposable will have such feature, but the other Disposables start in the usual, slow way.
