On 11/08/13 22:00, Axon wrote:
> On 11/08/13 05:48, Joanna Rutkowska wrote:
>> On 09/29/13 20:02, adre...@gmail.com
>>> Disposable VMs run entirely in RAM?
>>> Let's assume for the sake of argument, that we're only up against local
>>> forensics. Not against network snooping.
>>> When a Disposable VM is closed, is it guaranteed, that there are no traces
>>> on the local harddrive? (What about swap?)
>>> Did anyone verify that claim using forensics? (One could image an
>>> installation of QubesOS, use a browser in a Disposable VM, image QubesOS
>>> again and then compare the images.)
>>> If DispVMs defeat local forensics, I'd say this is a big advantage of
>>> QubesOS / DispVMs and should be advertised as such in documentation.
>> It does not.
>> Each DispVM uses volatile.img file that is used to create R/W illusion
>> for its root fs via COW (same mechanism as for any other AppVM based on
>> a template). This file is located in
> So, what does the "Keep dispVM in memory" option do? (Qubes VM Manager
> --> System --> Global Settings)
The intention was for this to control whether the *savefile* is kept in
RAM (to speedup DispVM startup) or not (not to consume precious RAM).
But, from a quick grepping throught the sources, it appears to me that
it does nothing. I.e. it only touches
/var/lib/qubes/dvmdata/dont_use_shm, but the latter is never used by any
of the core code.
So, I think we should make this option grayed out in the manager, and
also change the label to something like: "Keep the DispVM savefile in
RAM to speed up DispVM startup" to make it clear what the intention is.
In the future we might add another switch that would be forcing the
volatile.img to be kept on /dev/shm as well, as discussed in the
Marek, am I missing something here?
>> (BTW, an interesting peculiarity, which you, like myself, might be
>> wondering about: when another DispVM is started this volatile.img, used
>> by the previous DispVM is unlinked, and so the new DispVM uses a new
>> copy of the file, inode-wise).
>> Theoretically, one could modify the conf file used for dispvm creation,
>> specifically this line (e.g. in
>> ... and change the path to point to /dev/shm/qubes, where the DispVM
>> savefile is kept, and which is stored in RAM entirely (the whole
>> /dev/shm is a ram-based fs).
>> But, as Marek pointed out, a DispVM which might got to the dark side of
>> the force, might then generate write to its whole root fs and make this
>> vaoltile.img file to swallow up to 10GB in size, making the whole system
>> unusable if we kept it in /dev/shm.
>> Unless we could setup some quote on /dev/shm, can we?
>> Anyway, regarding your forensics concerns -- a rather easy and
>> convenient way to remove any records of a particular AppVM's activities
>> is to simply shred its private and volatile images:
>> shred private.img volatile.img
> But this is probably ineffective on certain file systems (see man page)
In practice journals only backup metadata, not actual blocks, at least
this is the case for the fs we have in Dom0.
> or on SSDs (due to wear leveling), correct?
Never investigated this from a practical persepctive, I tend to believe
the risk is just theoretical.
>> ... and then remove it normally:
>> qvm-remove <appvm>
> It sounds like the DispVM page
) should probably be updated
> to reflect this information, since I think most Qubes users have assumed
> that DispVMs run entirely in RAM. If you agree, I can update the page
> (though I still do not completely understand how DispVMs actually work).