I have a background in software engineering and cyber security and so this specific question has been on my mind for quite some time now. When I speak of AppVMs in this post, I am referring to non-disposable AppVMs which have their own persistent storage and will retain (some) changes to their file systems and settings across reboot. The questions:
What are the precise static vs ephemeral directories on Windows that are preserved or discarded when a Windows AppVM shuts down?
If a Windows Update were to take place in the TemplateVM that other Windows AppVMs are derived from, should these updates now be applied to ALL dependent AppVMs? If so, is it the case that all of the AppVMs would need to be rebooted to reflect this change?
These two questions factor into my primary, more technical question: what are the precise file system, registry, etc operations made from a Windows AppVM which will be discarded on boot? Similarly, which are the precise file and registry operations made on a Windows TemplateVM which will persist across all of its derived AppVMs?
Practically speaking, my assumption would be that directories such as “Program Files” and “System32” would be immutable from an AppVM: any changes made to them would be discarded when the AppVM is shutdown. Am I correct in assuming this? And if so, what are the “AppVM-specific” directories whose contents DO persist between reboots in an AppVM?
For further clarification, the way this seems to work on the Linux templates that come with Qubes is that they will persist modifications to the contents of the user’s home directory across reboots (assuming it is not a disposable VM, but that is not what I am referring to here), while all other file system modifications will be discarded.
Thank you for your insights. I am come to have a great deal of respect for the technical expertise of the users on this forum.
In a standard Windows TemplateVM installation, where the Option Move User Profiles was selected, the directory C:\Users\ is moved to Q:\Users\, whereas all other directories are left in their original location, normally on C:.
That means that all software in one of the standard program directories Program Files, Windows etc. is reset to its original state on reboot of an AppVM based on that template. Any changes to the registry keys HKEY_LOCAL_MACHINE and HKEY_SYSTEM are also lost on reboot of the AppVM.
On the other hand, user data in the documents folder, user-specific changes to the registry key HKEY_CURRENT_USER, and program parameters in the AppData directory survive reboots.
For Windows 7 and 10, this behavior is rather consistent, while, in Windows 11, the AppData directory on my machine or, at least the links pointing to it, were left on drive C:. I have no idea if this happened just in my installation, or if this is so in any Windows 11 system. Anyhow, user data in the Documents folder were moved to drive Q: and behave as in the other Windows versions.
Unfortunately I do not recall if I selected “Move User Profiles” when I installed QWT. Can you clarify if everything else that you wrote is still relevant in the event that I did not? And how I can go about checking this?
Windows 7 (May not pertain to other version) open up file manager, open up computer, and hopefully you’ll see a drive Q: listed. That should have your user directory in it (perhaps nested inside another folder; I can’t recall (and can’t check)).
If there is no drive Q, or there is and it doesn’t contain your directories, then you didn’t check Move user Profiles. (Or you did and it failed for some reason.)
I took a great interest in this topic and decided to make some tests for myself to validate the behavior I am seeing.
A Win10 template was created and a test file was created in:
C:
C:\ProgramData
C:\Program Files
C:\Windows\System32
and in HKLM\SOFTWARE in the Registry
Then shutdown the Template VM.
Next, an AppVM non-disposable was created from it. This AppVM could
see all of the test files. From the AppVM I added my own set of test
files and shut down the AppVM.
I booted into the Template VM and I can see none of those new files
created by the App VM.
I add a second set of new test files in the same file and registry
locations from the Template VM once again, and shutdown.
I booted into the AppVM and I only see the original set of test files
created from the TemplateVM (before the AppVM was created from it) AND
the test files created from the AppVM during its last boot.
Conclusions:
The App VM and Template VM seem to have absolutely no relation to
each other once the App VM is created: its initial state will mirror
that of the Template VM at the time it was created and the two will
diverge from there.
Windows Updates will need to be installed in BOTH the Template VM
and the App VM. The concept, as in the built in Fedora App VMs, does
not seem to apply here to Windows wherein you update the central template
VM and then that update is applied to all of the child App VMs.
The App VMs are not resilient to exploitation or malware. If I am
using my Windows App VM to view a PDF file, which turns out to contain
an exploit and installs malware on my App VM, that malware will now
have full access to everything I ever do on that App VM from this point
onward and will persist across reboots. 4. I see no benefit in using a Windows App VM unless it is disposable for example to do web browsing or other user activity that could expose the VM to a malware infection. And even then, based on what I have seen in my own testing (that Windows Updates applied to the Template VM will not persist to its App VMs) it doesn’t even seem like a good option in this scenario either.
For further clarification here, I did not select “Move User Profiles” as part of the configuration of either of these VMs.
Have I misconfigured my Windows App VM or are these known issues I am seeing?
In Qubes philosophy any AppVM is considered to be compromised by default, regardless of the OS.
Using AppVM based on any templates makes more than sense, because it always can be created again when compromised.
What it counts is that templates, offline qubes (reasonably) and dom0 are safe.
I checked now with a Windows 10 Template VM with the Move User Profiles option enabled and with an AppVM based on it. This combination works as expected:
Any files created on drive C: are lost on reboot of the AppVM.
Files created on drive Q: survive the reboot.
Updates installed on the AppVM are lost on reboot.
Updates installed on the TemplateVM are passed to the AppVM if it is started after the TemplateVM has been restarted and then shut down again. On the first start after this sequence, the AppVM may execute a part of the installation again, but after its next start, the installed software is available in the AppVM.
This behavior is equivalent to that of Linux qubes and shows that any malware that modified part of the system data is destroyed on reboot of the AppVM. Only modifications to the private data on drive Q: survive a reboot. So installing a Windows TemplateVM with with the Move User Profiles option provides good protection.
As far as I remember - but I did not test it again - Windows 7 behaves the same way, whereas my Windows 11 installation seems to mix data on both drives in some way that is not really clear to me.
Combining your and my test results leads to the conclusion that, in Windows, you will get good protection via the template mechanism if and only if the Move User Profiles option is used during QWT installation.
I am on Windows 7 (I really ought to think about an upgrade, now that I can do it in a way that disables the spyware aspects of W10) and unless I am somehow out of date [which wouldn’t surprise me!], that’s how it works.
Alas some software requires W10. (Of course there’s no reason you can’t have both as qubes.)
Even software that says it will run on W7 often requires SP1 (and doesn’t say so). I was finally able to figure out how to upgrade my W7 standalone box to SP1 a few months ago. (This is moot on qubes because the ISO is a W7SP1 ISO.) It turns out just buying an installation disk for W7SP1 won’t do it; it will refuse to upgrade because you don’t have W7SP1 installed! It tries to force you to do a complete fresh install! Yes, I kept copious notes in a vault-style qube.
The biggest problem I have with Qubes Windows 7 is getting it activated…you can’t do it over the phone any more, at least I’ve never managed it.
I need to check to see which one is needed for DaVinci though it probably won’t work at all on the “Qubeville” box (needs major graphics card), only my standalone.
An installation kit for Windows 7 SP1 can be downloaded from the Microsoft support website; it has the number KB976932 and a size of 912.4 MB for 64 bit systems, which are required by Qubes. According to Microsoft documentation, it upgrades the existing system to SP1 without requiring a new installation. For troubleshooting, this installation, see the installation instructions.
I thought that was the page I remembered from before. I finally got to looking at it.
Online activation is out for me…that qube never touches the internet.
The command line methods at the end don’t work. I’ve tried them before and now it won’t even let me do the slmgr -rearm because I’ve done it too many times. (slmgr -ato simply did nothing.)
As near as I can tell the only thing I lose for not having it activated, honestly, is the desktop wallpaper. Oh, and it pops up nags everywhere, all over my Qubes system.
That doesn’t really surprise me. One of the things I love with Windows is that many / most of the tips on how to fix something often don’t work at all. And then some people complain about Linux
Oh, Linux breaks plenty but I can often figure it out…provided it’s not a hardware or boot issue. (You wouldn’t believe how much hoop-jumping I did to finally get browser VMs set up the way I want them, yesterday.)
