Failure_to_wipe_memory_when_RAM_disk_is_full.mdwn 2.78 KB
Newer Older
Tails developers's avatar
Tails developers committed
1
2
Problem: When the RAM disk is full, Tails fails to shutdown correctly
and wipe the memory when the boot device is unplugged.
127.0.0.1's avatar
127.0.0.1 committed
3

Tails developers's avatar
Tails developers committed
4
5
6
7
Reproduction: I encountered the problem with SD flash cards and it
probably also happens with normal USB sticks. Boot Tails from the USB
stick, create a huge file (cat /dev/zero > /home/amnesia/test.dat) and
unplug the stick when cat is finished.
127.0.0.1's avatar
127.0.0.1 committed
8

Tails developers's avatar
Tails developers committed
9
10
11
12
13
14
Symptoms: Tails either stays in graphical mode, does not shut down at
all and does not allow the user to run any program, or it shuts down X
but hangs itself up in console mode, printing 'Unable to read page,
block entry ....' or 'Unable to read data cache entry' nonstop. After
a hard reboot, an adversary can copy the RAM contents of the previous
Tails session (normal boot attack).
127.0.0.1's avatar
127.0.0.1 committed
15

16
17
18
19
20
21
22
23
> 1. Are you *sure* this *only* happens when the RAM is full? If it
>    really does, we could probably ask kexec to load the kernel
>    and ramdisk at boot time rather than at shutdown time to make
>    failure less frequent; anyway, unless we tell the kernel to keep
>    some spare memory that would be reserved for the emergency halt
>    procedure (which I'm not sure we can easily do without diving
>    into cgroups and alike), we have to be prepared for software to
>    behave in weird ways when it is given no memory to do its job.
127.0.0.1's avatar
127.0.0.1 committed
24

127.0.0.1's avatar
127.0.0.1 committed
25
26
27
28
29
30
> It happens also when the RAM is not completely full. I have 1GB RAM on
> the machine I'm currently testing, and when more than about 3/4 of
> the RAM is full the weird behaviour starts - sometimes. When it's
> completely full, the error *always* comes up. I guess adding
> the rest of the required files to memlockd and/or removing GDM
> with SIGKILL could solve the issue. --JohnDoe
127.0.0.1's avatar
127.0.0.1 committed
31

32
33
34
> 2. Can you reproduce this by a. filling the memory and b. shutting down
>    Tails "normally" i.e. using the GNOME buttons?

127.0.0.1's avatar
127.0.0.1 committed
35
36
37
> This always works, except when I fill the home directory and the
> /tmp directory to the limit. Tails freezes in X mode when I do that
> and becomes unresponsive to anything except hard reboot.  --JohnDoe
127.0.0.1's avatar
127.0.0.1 committed
38

Tails developers's avatar
Tails developers committed
39
40
Probable reason: Virtual filesystem does not keep neccessary files in
memory.
127.0.0.1's avatar
127.0.0.1 committed
41

Tails developers's avatar
Tails developers committed
42
43
Probable solution: Force squashfs to keep certain files, especially
the shutdown scripts and the files required for kexec, in memory.
127.0.0.1's avatar
127.0.0.1 committed
44

Tails developers's avatar
Tails developers committed
45
46
--JohnDoe

47
48
49
50
51
52
> Already done using memlockd, see [[memory erasure implementation
> notes|contribute/design/memory_erasure]] for details. Sounds like we
> may have missed a few files, though: `/etc/init.d/gdm3 stop` is
> called by `/usr/local/sbin/udev-watchdog-wrapper` but we lock
> neither this initscript nor the files it itself uses into memory.

127.0.0.1's avatar
127.0.0.1 committed
53
>> Do we need to stop gdm using the init-scripts instead of, let's say, kill -9
127.0.0.1's avatar
127.0.0.1 committed
54
>> when doing the *emergency* shutdown? --JohnDoe
127.0.0.1's avatar
127.0.0.1 committed
55

Tails developers's avatar
Tails developers committed
56
57
>>> Tails 0.9 uses pkill and fixes at least that probable cause.
>>> Can anyone still reproduce the bug, or should we close it?