Skip to content

Commit 9bb3cee

Browse files
ben-grandeben-grande
committed
Announcement: Preloaded disposables
1 parent af325a6 commit 9bb3cee

1 file changed

Lines changed: 154 additions & 0 deletions

File tree

‎2025-07-10-preloaded-disposables.md‎

Lines changed: 154 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,154 @@
1+
---
2+
layout: post
3+
title: "Qubes Architecture Next Steps: Preloaded diposables"
4+
categories: articles
5+
author: Benjamin Grande
6+
---
7+
8+
<!--
9+
TODO: reviewer: when posting, rename this file with correct date.
10+
TODO: reviewer: when posting, rewrite the paragraph below:
11+
12+
This is the second article in the "What's new in Qubes 4.3?" series. You
13+
can find the previous one (about GUI Domains)
14+
[here](/news/2020/03/18/gui-domain/). While the
15+
introduction of GUI domains is a big, singular feature, the changes to
16+
qrexec are more complex and varied --- but also very important.
17+
-->
18+
19+
## What are disposables
20+
21+
A [disposable](/doc/how-to-use-disposables/) is a lightweight qube that can be
22+
created quickly and will self-destruct when closed. Disposables are usually
23+
created in order to host and execute untrusted code, being it on the software
24+
level a single application, like a viewer, editor, web browser as well as on
25+
the hardware level with [PCI passtrough](/doc/how-to-use-pci-devices/).
26+
27+
There are two kinds of disposables, unnamed and named. The difference between
28+
them (besides one having a fixed name) is that unnamed disposables are
29+
destroyed when closing the first application opened in them while named
30+
disposables require an explicit shutdown operation to be made by the user.
31+
32+
## Fresh disposable startup time leads to fatigue
33+
34+
The most secure workflow for segregation of duties requires always using a
35+
fresh disposables, named disposables are discarded. So what is the problem
36+
with unnamed disposables? The caller has to wait for a complete qube startup
37+
before running the desired application. The delay might seem a minor annoyance
38+
at first, but over a prolonged period, fatigued users run applications on
39+
already tainted qubes or in the qube itself to avoid the waiting time.
40+
41+
There is no lack of understanding that using disposables is more secure than
42+
not using it, the problem is not documentation but how the user perceives the
43+
system. If the system is slow, the user will circumvent that slowness even
44+
if means compromising their security, cause they just want to get things done.
45+
46+
The slowdown is aggravated when requesting a high number of disposables
47+
sequentially, which happens constantly when using the Qubes Executor to
48+
[build QubesOS](/doc/qubes-builder-v2/).
49+
50+
A secure workflow should not be a burden. Can QubesOS do better?
51+
52+
## What are preloaded disposables
53+
54+
Yes! It can do better.
55+
56+
Preloaded disposables are unnamed disposables started in the background and
57+
kept hidden from the user when not in use. They are interrupted (paused or
58+
suspended, as appropriate) and resumed (transparently) when a disposable qube
59+
is requested by the user.
60+
61+
When the qube is preloaded, the qube application listing or the qube entry
62+
itself is hidden from GUI applications such as the app menu and the Qrexec
63+
Policy Ask prompt. This is by design to avoid contamination, a preload is not
64+
something you use directly, but indirectly.
65+
66+
The use of preloaded disposables is transparent, indistinguishable from the
67+
usage of unnamed disposables. Requesting the creation of a new unnamed
68+
disposable will instead mark a preload a used and reply with an already
69+
running preloaded disposable, followed by the creation of a substitute. A
70+
preload that is marked as used ceases to be a preload, it's applications
71+
entries become visible on the GUI applications and there is discrepancy
72+
between it and other unnamed disposables.
73+
74+
Usage of disposables that have completed the preloading stage is almost as
75+
fast as executing code on an already running qube, just a bit slower because
76+
it has to unpause the qube as well as start the GUI agent. While unpause can
77+
take just a few milliseconds, waiting for the GUI agent can take a second. The
78+
remaining time is necessary for any operation across [domains](/doc/qrexec/).
79+
80+
In case of failure to preload due to any reason such as lack of available
81+
memory or the daemon responsible for managing qubes, `qubesd`, stops, no user
82+
interaction is needed, the system will fill gaps of missing preloaded
83+
disposables while removing incomplete ones.
84+
85+
## How to use preloaded disposables
86+
87+
Preloading is a "set and forget" operation, configure it once, setting the
88+
desired maximum number of preloaded qubes you would like to have preloaded and
89+
the system takes care of the rest, including filling the gaps of used
90+
preloaded qubes.
91+
92+
The only action required to preload a disposable is to set the feature
93+
`preload-dispvm-max` to the disposable template of disposables you most use.
94+
Consider a user that does a lot of management operations, such as
95+
[Salt](/doc/salt/) or use `qvm-console-dispvm`, they default qube for those
96+
operations is the `default-mgmt-dvm`:
97+
98+
```shell
99+
qvm-features default-mgmt-dvm preload-dispvm-max 2
100+
```
101+
102+
If you use a lot the global `default_dispvm`, you can target the global
103+
preload setting for that specific disposable template by setting the feature
104+
on `dom0`:
105+
106+
```shell
107+
qvm-features dom0 preload-dispvm-max 3
108+
```
109+
110+
While the disposable template remains the global `default_dispvm`, it will
111+
respect the global feature and ignore the per-qube setting.
112+
113+
To remove the unload all the preloaded qubes, set the feature value to `0`,
114+
`''` (empty) or delete the feature. In case the feature is set to `dom0`, the
115+
deletion is preferred for the preload setting to be read from the disposable
116+
template itself and not be capped to `0`.
117+
118+
The limit of the number of preloaded disposables you can configure is how much
119+
your system can handle. If there is not enough available memory to preload, it
120+
is skipped until another distinct event triggers it. However, GUI applications
121+
that allow preload configuration have a hard-limit of `50`, which should be
122+
enough for most use-cases.
123+
124+
<!--
125+
TODO: ben: photos
126+
127+
- Photo of Qubes Global Config
128+
- Photo of Qubes VM Settings
129+
130+
-->
131+
132+
## Performance improvements
133+
134+
<!--
135+
TODO: ben: graphs here would be nice, but percentage would also be ok I'd say.
136+
137+
- How fast compared to execution in a fresh disposable (use GUI and non-GUI
138+
RPC)
139+
- How fast compared to execution in an already running qube (use GUI and
140+
non-GUI RPC)
141+
- How much faster have builds become?
142+
143+
-->
144+
145+
## Know drawbacks
146+
147+
The preloaded disposables are paused when they finish preloading and haven't
148+
been requested for use yet. Paused qubes still still consume allocated memory
149+
and this stale state does not allow [memory redistribution](/doc/qmemman/).
150+
151+
Preloaded multiple disposables works even on systems with minimum system
152+
requirements having 8GB of RAM, the experience however, may not be the best
153+
when having little available memory. Systems with a lot of unused memory won't
154+
notice a difference.

0 commit comments

Comments
 (0)