I’m wondering that since ramdisks are easily possible in Linux distros via tmpfs,
I wonder how feasible it to make and use them in QubesOS considering that it works by using isolated virtual machines.
What prompted me to ask this is I read something interesting right here.
To quote from this page…
What if someone literally steals your laptop while you’re working with classified information inside a Whonix DispVM? They’d also be able to recover data from previous DispVMs–as Disposable VM’s rootfs virtual files are not securely shredded after your DispVM is destroyed. *
This immediately brought to mind ramdisks which, theoretically, can properly shred any data written in once the computer shuts down. But I wonder how it can be possible to run a Qube in a ramdisk, presuming its possible to even make a ramdisk in QubesOS.
I dont care about that - it’s just a copy of the template / and is
removed when the ramdisk qube is closed down.
What I do care about are changes to / in the qube, and those changes
are recorded in volatile which is stored on the ramdisk.
I’ve tested this pretty extensively, and ,(outwith use of swap), I dont
see any data from a session retained on disk.
It’s an easy solution that any one can use right now.
This is done to extract the LUKS master key from kernel memory and if done carefully could also reveal most of ones ramdisk. Therefore I would consider using a ramdisk for antiforensics not suiteable. Buskill on the other hand seems a reasonable approach to me.
Anyway, I run a couple of VMs in RAM because of performance. Modifications of the root partition being stored on SSD isn’t a bummer in this scope.
This is true - which is why I referred to data being “retained on disk”
But I feel that a ramdisk qube is ideal for antiforensics - certainly
better than a standard qube, where the data is immediately present on
As to Bus kill, I think it ideal in the case of “drive by” theft, where
the laptop is snatched in use. In that case, it is unlikely that the
thief would be using any forensics to recover data.
In the case of a targeted attack, I think Bus kill is pure theatre.
Dread Pirate Roberts is working away in the library, safe in the
knowledge that his Bus kill cable is attached to his belt.
Suddenly his arms are grabbed and he is pushed to the desk, the
arguing couple swing by, fix the two parts of the bus kill together,
and cut the belt loop securing the carabiner. Laptop is removed with
bus kill cable safely attached, and DPR is hosed.
The idea that Bus kill provides safety to Activists or Journalists
working in any sort of regime, oppressive or not, is imo grossly misleading.
I didn’t make myself clear. Modifications to the root partition are not stored on SSD but are
held in RAM. (They are on the volatile device, which is in the ramdisk
I’m glad you have found them of use.
I never presume to speak for the Qubes team.
When I comment in the Forum or in the mailing lists I speak for myself.
The bus kill sure is not a reliable protection against targeted attacks. But there are different ways to achieve the reliable kill switch, for example:
Saying the code word to initiate a shutdown by using microphone and speech recognition software. To avoid the microphone jammers send periodic encoded messages with loudspeaker and receive them with microphone and shutdown if it can’t receive them.
Use portable bluetooth device to press a button on it (or some other action) to send the message to initiate a shutdown. To avoid jammers the device can send periodic encoded messages and shutdown if it can’t receive them.
Though if they know how you’ve protected your system and you’ll be held instantly by multiple strong people then there’s no way you can do anything.
One could allocate additional RAM from Xen to dom0 and then use a ramdisk** there into which one has created a btrfs partition or lvm pool then define a qvm-pool to which one copies templates into for dispVM usage.
It would be nice if Xen itself provided a ramdisk primitive that could be made available in dom0 but at the moment it does not. So allocating the additional RAM to dom0 for a dom0 managed ramdisk would be the only way currently.
dom0 can participate in memory balancing so one should choose a ramdisk driver that deallocates reliably when storage is released to ensure other VMs can access the free memory via xen allocation when not in use by dom0/ramdisk.
** I find it very frustrating that the standard terminology for the post kernal-load minimal system bootstrap stub for Linux is called a ramdisk, as it makes queries into “other” types
of ramdisk usage under Linux difficult…
You can’t make a 6 GB drive without giving dom0 6 GB extra memory
I still can’t confirm what you are writing.
However, thank you for pointing into that direction. I’m suspecting that my dom0 is partially using /dev/mapper/qubes_dom0-swap for my ramdisk. Which would defeat it’s purpose performance-wise and antiforensic-wise.
Let’s say a VM (just a regular VM, like the installed versions of ‘personal’ or ‘vault’, not one running in RAM) creates a ramdisk, via sudo mount -t tmpfs -o size=1m tmpfs /home/user/Ramdisk (or something like that).
Is that ramdisk actually in RAM or is it really part of some file in dom0?