Commit 5f588e52 authored by intrigeri's avatar intrigeri
Browse files

Merge remote-tracking branch 'origin/bugfix/12354-drop-kexec-memory-wipe' into...

Merge remote-tracking branch 'origin/bugfix/12354-drop-kexec-memory-wipe' into feature/stretch (Fix-committed: #12428, #12354)
parents 29918347 33085184
[[!toc levels=2]]
# Prepare the needed tools
We will use a minimal Debian Lenny Live system to set up a coldboot
Why minimal? So that it doesn't overwrite too much of the RAM we want
to analyze.
Why Lenny? To be able to grep `/dev/mem`, one must run a kernel that
has `CONFIG_STRICT_DEVMEM` disabled. This setting has been enabled in
Debian kernels since 2.6.28-1, so we use lenny.
<div class="note">
It is no more possible to build such an image from the Debian archive. Ask if you need to one to run these tests.
Then install this image on a USB stick.
# Dump the RAM
Grep'ing `/dev/mem` does not work on systems with large amounts of
memory, so let's use `dd`.
RAM_SIZE_IN_KB=$(free -k | awk '/Mem:/ { print $2 }')
dd if=/dev/mem of=$DUMP bs=1K count=$RAM_SIZE_IN_KB oflag=direct
where `$DUMP` is some large enough storage for dumping your entire RAM
into. It could be a USB drive, but I'd recommend a fast harddrive
unless you want to wait for half an hour or more. The longer the dump
takes, the more RAM may be overwritten, so speed is crucial, actually.
One problem is that the live system built above doesn't include
cryptsetup, lvm2 and friends, so you'll need an unencrypted partition.
The point is to get `$RAM_SIZE_IN_KB` exactly right -- it should be in
kilobytes of the 1024 bytes variant. The important thing is just to
get bs and count in such a way that dd reads as much of your RAM as
possible, but *NOT* more. Also, bs should be small since dd allocates
that much memory for its own buffer, and that will overwrite RAM.
oflag=direct will ensure that no cache is used, which otherwise would
start to over-write RAM for buffers.
[[!toc levels=2]]
# Prepare the needed tools
## Memory scrapping software
Sources are available there:
* <>
* <>
0. Check the tarball signature, unpack.
0. On an amd64 system run:
$ make -f Makefile.64
## DHCP/TFTP server
If you already have a DHCP/TFTP server ready (e.g. thanks to libvirt),
all you need to do is to make your tftp root point to
`bios_memimage/pxe`, and set `scraper.bin` in the place of the
boot loader.
Else, dnsmasq will happily provide both a DHCP and a TFTP server,
using the following command line:
$ sudo dnsmasq --conf-file=/dev/null \
--interface=tap0 \
--dhcp-range=,,1h \
--enable-tftp \
--tftp-root=/tmp/bios_memimage/pxe \
--dhcp-boot=scraper.bin \
(Adjust `tftp-root` and `interface` according to your setup.)
Don't forget to punch enough holes in your firewall so that DHCP, TFTP
and port udp/31337 will go through.
# Run Tails in qemu/kvm
* Start kvm (using a tap interface, in order to
be on layer 2 between host and VM, otherwise DHCP won't work.)
$ kvm -boot nd -net nic,macaddr=0:0:e8:1:2:3,model=rtl8139 -net tap -m 1024 -cdrom tails.iso
* Setup an IP address on your interface:
sudo ip addr add dev tap0
sudo ip link set tap0 up
* Press 'Q' to disable PXE for the initial boot. Let the Tails DVD boot.
# Dump the RAM
* At boot time, press 'N' to enable PXE boot. You should soon see
`Waiting for handshake...`
* Start the dumping process:
pxedump | pv > tails.dump
# Final note
By replacing `tap0` with `eth0` in the previous examples, it should be
fairly easy to reproduce this for bare metal hardware, provided its
network adapter and BIOS are PXE-ready.
* Start the VM
- with a 64-bit CPU that supports PAE
qemu-system-x86_64 -enable-kvm -cpu Nehalem -cdrom tails.iso -m 5120
- with a 32-bit CPU that does not support PAE
qemu-system-x86_64 -enable-kvm -cpu 486 -cdrom tails.iso -m 5120
* Open the qemu console (CTRL-ALT-2).
* Save physical memory to the `tails.dump` file (length is an integer, max size for one dump is 4G = 0xF0000000):
pmemsave <start address> <length> <filename>
e.g for 5G one has to do two dumps:
pmemsave 0 0xFFFFFFFF tails14.dump
pmemsave 0x100000000 0x40000000 tails5.dump
Run the following from the host:
vboxmanage debugvm "${VM_NAME}" dumpguestcore --filename tails.dump
and that's it.
VirtualBox' VM core is an ELF that contains [some headers and other
state]( of
the Tails guest in addition to the memory dump, but there's no
reasonable possibility of finding the pattern as false positives there
so there's no reason to bother cutting the headers away.
......@@ -106,7 +106,7 @@ Additional features
* Some basic [[doc/first_steps/accessibility]] features
* Some [[contribute/design/application_isolation]] with AppArmor
* To prevent cold-boot attacks and various memory forensics, Tails
erases memory on shutdown and when the boot media is physically
erases most memory on shutdown and when the boot media is physically
Multilingual support
......@@ -16,19 +16,6 @@ attack"]] </span>. To prevent this attack, the data in RAM is
overwritten by random data when shutting down Tails. This erases all
traces from your session on that computer.
<div class="bug">
On some computers Tails might fail to:
<li>[[erase all the data in RAM on
<li>[[completely shutdown or restart|support/known_issues#fails-to-shutdown]]
(in this case there is no guarantee that all the data in RAM is
Moreover, an attacker having physical access to the computer *while
Tails is running* can recover data from RAM as well. To avoid that,
learn the different methods to [[shutdown
......@@ -669,9 +669,8 @@ Can I use the memory wipe feature of Tails on another operating system?
The memory wipe mechanism that Tails uses on shutdown to [[protect against cold
boot attacks|doc/advanced_topics/cold_boot_attacks]] is not yet available in
other Linux distributions. In the future, we would like to package it for
boot attacks|doc/advanced_topics/cold_boot_attacks]] should be reusable in
other Linux distributions.
If you want to implement this feature outside of Tails, have a look at the
corresponding [[design documentation|contribute/design/memory_erasure]].
......@@ -406,50 +406,6 @@ the DVD anymore.
See [[!tails_ticket 5447 desc="Fix DVD eject at shutdown"]].
<a id="fails-to-shutdown"></a>
Tails fails to completely shutdown or restart
When stopping Tails on some hardware, the memory wipe procedure fails to
complete: the display gets scrambled, but the computer doesn't
completely shutdown or restart. Sometimes the caps-lock button light of
the keyboard flashes.
<div class="caution">
When this happens, there is no guarantee that the memory is wiped entirely.
This issue has been reported on the following hardware:
- Acer Aspire e1-572
- Apple when booting from a USB stick:
- MacBook Air 5,1
- MacBook Air 5,2 (using a device installed with Tails Installer)
- MacBook Air 6,2
- MacBook Pro 7,1 13-inch (mid 2010)
- MacBook Pro 9,2 13-inch (mid 2012)
- MacBook Pro 8,1 13-inch (late 2011)
- MacBook Pro 10,2
- MacBook Pro Retina 11,1 (late 2013)
- MacBook Pro Retina 13-inch (early 2015)
- Dell Inc. Studio 1458
- Dell Latitude E6230
- Dell XPS 8500
- Fujitsu Lifebook AH531/GFO, only on regular shutdown, emergency
shutdown works
- Hewlett-Packard HP ENVY x360
- Hewlett-Packard HP Pavilion dv6 Notebook PC
- Hewlett-Packard HP ProBook 450 G0
- Lenovo ThinkPad X61, only on emergency shutdown when pulling out the
USB stick
- Lenovo ThinkPad X220
- Microsoft Surface Pro 3
- Samsung N150P
- Toshiba Satellite C855D
<a id="fingerprint"></a>
Browser fingerprint
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment