Store volatile.img in separate location

[marmarek]

@v6ak https://groups.google.com/d/msgid/qubes-users/1f975e13-45bb-4146-b651-a59b07560a29%40googlegroups.com

I am trying to move my volatile.img files to another location. There are
two (three) reasons for it:

1. Some additional secrecy; the filesystem is encrypted by a password from
   /dev/random, so no one can read the volatile.img files after reboot.
2. Performance (+ reduces wear when used with SSD): The filesystem for is
   tuned for performance at the cost of consistency when computer is forcibly
   turned off. This is undesirable for main FS, but OK for a dedicated
   filesystem for this purpose.

I have prepared such a temporary filesystem to be mounted under /largetmp.
(Well, I might change it just to /tmp.) There is nothing I have problem
with, so I'll share the details below.

Now, I would like to move all the volatile imgs there. I have grepped for
volatile.img in Qubes sources. The easiest (though somewhat hacky) way to
do this seems to be adding the following line before truncate command to
/usr/lib/qubes/prepare-volatile-image.sh:
ln -s "/largetmp/volatile-$(printf %s "$FILENAME" | base64 -w0 | sed
's#/#:#g')" "$FILENAME"

(...)

Linked message contains also PoC

Related to #904

[andrewdavidwong]

@v6ak: Just checking in. Did you happen to continue to do any work on this after your last update? Any further progress or findings you're willing to share with us would be much appreciated!

[andrewdavidwong]

@v6ak: Just checking in. Did you happen to continue to do any work on this after your last update? Any further progress or findings you're willing to share with us would be much appreciated!

[v6ak]

It seems that it is up-to-date. As a quick hack for 3.0 (and probably also for 3.1, though it might require minor changes), it seems to work perfectly.

A clean solution, would, however, require some code refactoring. As far as I remember, the current code for 3.0 (and probably also for 3.1) assumes that volatile.img is located in the VM's directory. I am not sure where are those assumptions made (it might be few places and is might be many different places as well), so I've decided to use the hacky symlink approach, which partially preserver the assumption of same directory for volatile.img.

And I am totally unsure what changes are brought by 3.2/4.0 branches. Either there might be some refactoring that makes this change easier or there might be something that breaks my approach and makes it even harder to refactor the code.

[v6ak]

It seems that it is up-to-date. As a quick hack for 3.0 (and probably also for 3.1, though it might require minor changes), it seems to work perfectly.

A clean solution, would, however, require some code refactoring. As far as I remember, the current code for 3.0 (and probably also for 3.1) assumes that volatile.img is located in the VM's directory. I am not sure where are those assumptions made (it might be few places and is might be many different places as well), so I've decided to use the hacky symlink approach, which partially preserver the assumption of same directory for volatile.img.

And I am totally unsure what changes are brought by 3.2/4.0 branches. Either there might be some refactoring that makes this change easier or there might be something that breaks my approach and makes it even harder to refactor the code.