Ramdisk in Qubes?

General Discussion
1

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.

1 Like
2

Read this:

2 Likes
3

It’s possible, and simple:

But note the caveat re forensic reliability, and the “tell” of having
such scripts at all.

Also, if this is a targeted attack, your ramdisks, and buskill, wont
help you at all.

I never presume to speak for the Qubes team. When I comment in the Forum or in the mailing lists I speak for myself.
4

@unman your notes at github are a gold mine.

I wrote a similar script based on the one you provided. However, xvda’s thin-lvm snap is stored on the device where the template is located. Naturally that is not the ramdisk.

Check

qvm-create new -P newer -t debian-11 -l purple --property netvm=tor

with

qvm-volume list --pool <ram’s pool> | grep new
qvm-volume list --pool <template’s pool> | grep new

5

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.

6

AFAIK confiscation of hardware is preferably done while ones hardware is switched on. Power supply is interrupted and the RAM is cooled down immediately:

https://ro.ecu.edu.au/cgi/viewcontent.cgi?article=1162&context=adf

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.

Thanks for sharing your notes on github.

1 Like
7

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
disk.

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
pool.)

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.
8
off-topic

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.

9
off-topic

But if you add webcam with image analysis to check for the situations where you’re being held down then it can protect you from this as well.

10

Doesn’t full memory encryption protect against cold boot attacks and similar attempts at dumping the memory?

11

I thought they are stored in the snap device?!?

[user@dom0 ~]$ qvm-volume list --pool poolram_qubes | grep disp
poolram_qubes:appvms/dispXXXX/private   dispXXXX  private      No
poolram_qubes:appvms/dispXXXX/volatile  dispXXXX  volatile     No
[user@dom0 ~]$ qvm-volume list --pool poolhd0_qubes | grep disp
poolhd0_qubes:qubes/vm-dispXXXX-root   dispXXXX   root   No
[user@dom0 ~]$ lsblk | grep disp
    │   ├─qubes-vm--dispXXXX--root--snap   x:y   0   10G   0 lvm   
        ├─qubes-vm--dispXXXX--root--snap   x:y   0   10G   0 lvm
[user@dom0 ~]$ sudo lvs | grep disp
 vm-dispXXXX-root-snap   qubes   Vwi-aotz--   10.00g poolhd0   vm-debian-root   43.57

The following must be some kind of thin-provisioning also

[user@dom0 dispXXXX]$ ls -lh
total 569M
-rw-r--r-- 1 root root 2.0G May 26 14:28 private-cow.img
-rw-r----- 1 root root 2.0G May 26 14:28 private.img
-rw-r--r-- 1 root root  10G May 26 13:45 volatile.img

as the ramdisk only has 6G.

Anyway… when it comes to LVM and thin-provisioning I have no plan. Is private-cow.img storing changes to xvda ??? Confused but loving it.

12

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.

B

** 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…

13

That can be done i.e. like this:

sudo mkdir -p /media/ramdisk
sudo /bin/bash -c 'echo "tmpfs   /media/ramdisk   tmpfs   rw,size=6G 0 0" >> /etc/fstab'
sudo findmnt --verify --verbose
sudo mount /media/ramdisk

No need to fiddle around with Xen or it’s memory balancing.

14

Without using balancing, it’s going to use 6 GB memory, even if the drive isn’t used.

15

I can’t confirm that. I’ve often 3 dispVMs running on ramdisk and they are eating up only like 1GB each. Try it out yourself. The filesystem does some kind of thin-provisioning.

16

You can’t make a 6 GB drive without giving dom0 6 GB extra memory, it doesn’t matter if you make the drive or not.

Unless you manually balance by editing grub, you would need to permanently increase the memory of dom0 by 6 GB.

17

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.

18

A related question.

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?

19

tmpfs is ram-based but contents can be swapped to the VM’s swap partition (written to storage) due to memory pressure, so perhaps not the best choice for anti-forensics.

ramfs is similar tech but cannot be swapped to storage … however with ramfs you must then be sure you don’t set yourself up to have OOM issues.

B

20

Thanks…this is a very small VM that does just one thing…and as you can see it’s a small ramdisk. Ramfs looks like what I want to be using.

1 Like