Luckily it is used as argument to commands with does not allow any
harmful arguments (virsh set(max)mem). Also usage in arithmetic
expression does not allow any harmful usage in this place.
This script is connected directly to calling process, so any output here
will disrupt qrexec service data. For example in case of qubes.OpenInVM
this will be prepended to modified file while sending it back to the
source VM - in case of no modification, it will override that file in
the source VM...
This allows to specify tight network isolation for a VM, and finally
close one remaining way for leaking traffic around TorVM. Now when VM is
connected to for example TorVM, its DispVMs will be also connected
there.
The new property can be set to:
- default (uses_default_dispvm_netvm=True) - use the same NetVM/ProxyVM as the
calling VM itself - including none it that's the case
- None - DispVMs will be network-isolated
- some NetVM/ProxyVM - will be used, even if calling VM is network-isolated
Closesqubesos/qubes-issues#862
Apparently it is much faster. Especially during savefile preparation -
tar reads the whole file, while bsdtar gets file map and reads only used
regions.
It have nothing to do with xenstore, so change the name to not mislead.
Also get rid of unused "xid" parameter - we should use XID as little as
possible, because it is not a simple task to keep it current.
Move DispVM creation to qfile-daemon-dvm/QubesDisposableVm from
qubes-restore. As actual restore is handled by libvirt, we don't get
much from separate qubes-restore process.
This code still needs some improvements, especially on performance.
Do not let hotplug script inherit lock FD - if it starts some long
running process (like xenstore-watch), it will hold the lock and block other scripts.
Apparently it doesn't work with some kernels - saved domain still needs
original memory amount to restore successfully. This happens at least on
3.12.14 kernel.
Because qfile-daemon-dvm always requests 400MB from qmemman, this change
should harm anyone - in any case DispVM needs 400MB free memory to
start.
Note that "xl mem-set" line is still there, which makes savefile somehow
smaller (so faster restore).
Opening a DispVM when the TemplateVM is running forces savefile
regeneration. Checking real root.img modification time (taking into
account root-cow.img) is tricky, so display a warning instead.
Now gui-agent supports reconnect to guid, so start it early to have Xorg
running in the VM.
This is still not done - for example it tries to run some commands via
(not running yet) qrexec.
It would work twice, but no more.
Also guard explicitely against buffer overflow, since once that
code actually works, sizeof(buf)-buflen will be interpreted as
large positive, and allow overwriting the stack.
It looks like a succesful read would have worked, assuming that the
other side always sends a \n last, as strtoul would find one before
the NUL. However, an error would write before the buffer.
