Preload disposables (Qubes 4.3)

[deeplow]

What is the feature you think should be a good addition to Dangerzone?

Dangerzone on Qubes is slow because it converts one document per disposable qube (VM). There are two ways to make it faster:

1. Convert multiple documents in the same VM (which would lead to malicious docs accessing all other ones)
2. Preload disposables so that they start immediately.

Option 2 will be possible in Qubes 4.3. The ETA for that is later in the year.

It's not the ultimate solution because if the default is preloading 3 qubes, then it just has 3 read for conversion, but it's better than none at all.

Is your feature request related to a problem? Please describe.

Yes. Slow conversion time on Qubes.

Additional context

The RAM availability should be a factor in determine if this feature should be used or not.

[almet]

Thanks for putting that on our radar. I got curious and looked-up if there was a way to detect when the disposable was used, for instance to preload another one, but the docs don't seem to mention that. Still, better than no preload!

[deeplow]

You're welcome!

I got curious and looked-up if there was a way to detect when the disposable was used, for instance to preload another one, but the docs don't seem to mention that. Still, better than no preload!

That's a good question. The system itself handles the preloading, so the client qube isn't aware of it by default. Although it can detect if it was preloaded or not by the startup time, which be near zero, when it comes to disposables.

Without any extra visibility, this time delta preloaded inference could be used to know how many conversions to do in parallel:

# pseudo-python

for doc in docs:
    start_time = time.now()
    p = async_subprocess("qvm-open-in-vm dz.convert @disp:dz-dvm")
    numpages = p.readbyte()
    startup_time = time.now() - start_time 
    if startup_time > 1:  # Exhausted preloaded
        block_until_first_exits()

Another possibility, which I'm certain is possible is to enable the management qube or client qubes for that matter to change the default disposable limit in the client interface and have that reflected in the real value.

[almet]

Thanks.

I was mainly thinking about the management VM (or dom0) knowing when disposables are used, in order to always boot another one, with the goal in mind to always have N numbers of preloaded disposable in the pool.

e.g:

• t0: 3 disposables are preloaded (pool = A, B, C)
• t1: 1 disposable is used (pool = B, C)
• t2: the management VM or dom0 detects there is just 2 in the pool where we want 3, and preloads D (pool = B, C, D)
• etc.

Of course, it doesn't seem that such a mechanism exist, but maybe it would be interesting to bring a discussion with the Qubes folks if we believe it's worth it (It's by no means blocking, just an idea to circumvent one of the current limitations of the system, but maybe I'm too far ahead)

[deeplow]

I was mainly thinking about the management VM (or dom0) knowing when disposables are used, in order to always boot another one, with the goal in mind to always have N numbers of preloaded disposable in the pool.

I haven't gotten to play around with it yet, but this is how I expect it to already be working. Always have a constant number of disposables ready to kick in at all times.

[ben-grande]

I was mainly thinking about the management VM (or dom0) knowing when disposables are used, in order to always boot another one, with the goal in mind to always have N numbers of preloaded disposable in the pool.

Managed automatically.

https://github.com/QubesOS/qubes-core-admin/blob/d95888ba1772428f26221d77046551d29f2c3930/qubes/vm/dispvm.py#L557

https://github.com/QubesOS/qubes-core-admin/blob/d95888ba1772428f26221d77046551d29f2c3930/qubes/vm/mix/dvmtemplate.py#L247

There is a brief mention that it manages the lifecycle automatically in the manpage:

https://github.com/QubesOS/qubes-core-admin-client/blob/main/doc/manpages/qvm-features.rst#preload-dispvm

As soon as the preloaded disposable is requested to be used, it is removed from the preload-dispvm list, GUI applications entries become visible, followed by a new disposable being preloaded.

But if you think there could be a documentation improvement, please open an issue on qubes-issues.

[deeplow]

Thanks for chiming in. I was considering pinging you, but you got to it first. @almet, for context @ben-grande was the one implementing the preloaded disposable logic.

[ben-grande]

Without any extra visibility, this time delta preloaded inference could be used to know how many conversions to do in parallel:

There is a benchmark script. Adapt it to run a benchmark. No need to block until a preload exist, if it doesn't, it will create a normal disposable and in the background, a preloaded will be created for the next call, if any.

Some benchmarks:

• short run
• full run

[ben-grande]

Without any extra visibility, this time delta preloaded inference could be used to know how many conversions to do in parallel:

There is a benchmark script. Adapt it to run a benchmark. No need to block until a preload exist, if it doesn't, it will create a normal disposable and in the background, a preloaded will be created for the next call, if any.

Some benchmarks:

* [short run](https://github.com/QubesOS/qubes-core-admin/pull/708#issuecomment-3131106079)

* [full run](https://github.com/QubesOS/qubes-core-admin/pull/708#issuecomment-3136624611)

I read it better now, you want to infer. That is possible, or you could write an event handler/hook that is triggered on domain-feature-set:preload-dispvm-max of the disposable template and write to vm-config of its descendants. Ideally, the client would already now that information, so it doesn't have to infer. If dom0 and template is updated simultaneous (a dream, I know, not always the case), you could hardocde on the client the maximum. Or, request the number via Qrexec call:

Policy:

admin.vm.feature.Get +preload-dispvm-max client dz-dvm allow target=dom0

qrexec-client-vm dom0 admin.vm.features.Get+preload-dispvm-max </dev/null

Example:

% qrexec-client-vm dz-dvm admin.vm.feature.Get+preload-dispvm-max </dev/null
0_4%
% qrexec-client-vm dz-dvm admin.vm.feature.Get+preload-absent </dev/null
2_QubesFeatureNotFoundError__Feature not set for domain dz-dvm: preload-absent_%