Why even use RAM- or VM-backed storage though, let alone both combined?
I asked about that but received no replies, so I just decided to proceed with it.
If you just want anti-forensics, then even without #10827 (i.e. the proper approach) it would be so much simpler to create an ephemerally encrypted disk image hosting a throwaway pool in dom0.
As mentioned earlier the goal of RAM qubes has never been anti-forensincs. The latter is just a positive side effect, as it turned out - welcomed by everyone. So, considering the main goal, RAM-backed storage is a requirement. There are 2 options:
-
consume dom0’s RAM (as done currently), potentially risking e.g. a dom0 deadlock due to improper tmpfs sizing or any other possible vulnerability e.g. a malicious VM leaving dirty stuff in dom0’s RAM, then dom0 process using that RAM
-
use domU’s RAM
I think the second could be better because it provides more flexibility and isolation. One can simply change the RAM size of sys-ramdrive and does not need to meddle in GRUB to increase dom0’s max memory.
If you have a better idea, I am very open to know about it.
Back on topic:
The observed behaviour seems buggy to me. Removing a device which is not unmounted and detached should not result in such overall system problems, especially considering it is completely unrelated to any qube that won’t start. Would you agree?