First, most memory is erased at the end of a normal shutdown/reboot sequence. This is implemented by the Linux kernel’s freed memory poisoning feature, more specifically:
page_poison- passing “P” to
slub_debug- zeroing heap memory at free time (
init_on_free=1)
That part was implemented into security-misc during Kernel Hardening thanks to @madaidan.
But other parts mentioned there are yet to be ported and packaged. Not a trivial copy/paste task because some parts are Tails / ISO specific.
We should advise users in the wiki to properly shutdown so this kicks in rather than forcing a shutdown (i.e. pulling the plug).
hardened-host-kernel also enables CONFIG_RESET_ATTACK_MITIGATION to wipe memory if the firmware supports it.
Some documentation on cold boot attack defense is indeed required.
I was wondering to add it here: https://www.whonix.org/wiki/Full_Disk_Encryption (FDE) - but strictly while it matters a lot for FDE it also matters for non-FDE and use with https://www.whonix.org/wiki/Host_Live_Mode. Created a stub here and added links to it:
In summary: says cannot be implemented using systemd. Should be done by the kernel.
Quote Lennart Poettering:
Uh, we can’t do that from userspace, we don’t even et access to that. This is something that needs to be implemented in the kernel, for example with a magic sysrq thing.
I think this feature requests has merits, but it really needs to be filed against the kernel as a feature request, systemd is not the right place where we could implement that.
Closing this here hence, I hope that makes sense?
Quote https://cateee.net/lkddb/web-lkddb/RESET_ATTACK_MITIGATION.html
Request that the firmware clear the contents of RAM after a reboot using the TCG Platform Reset Attack Mitigation specification. This protects against an attacker forcibly rebooting the system while it still contains secrets in RAM, booting another OS and extracting the secrets. This should only be enabled when userland is configured to clear the MemoryOverwriteRequest flag on clean shutdown after secrets have been evicted, since otherwise it will trigger even on clean reboots.
So the kernel has support for RAM wipe when firmware supports it.
Does the kernel also support RAM wipe if the firmware does not support it? If no, worth writing a feature request against the kernel?
Apart from init_on_free and so on, no.
No, the firmware is what wipes RAM. The kernel just enables that feature in the firmware. The kernel isn’t able to wipe all of the RAM itself which is why it must be done at a lower level like the firmware or Tails’ magic.
Is it worth porting the Tails magic to Whonix / Kicksecure?
My post is presupposing that one has read this page beforehand:
https://tails.boum.org/contribute/design/memory_erasure/
Tails has a test for this:
https://0xacab.org/tails/tails/-/blob/master/features/erase_memory.feature
^ that is a test definition file but pretty cool and human readable.
The test concludes with:
Then I find very few patterns in the guest’s memory
Which means the definition (the actual not so easily readable implementation of that human readable summary in source code) has some acceptance for leftover memory traces. Here it is:
https://0xacab.org/tails/tails/-/blob/master/features/step_definitions/erase_memory.rb
Relevant part:
max_coverage = 0.008
I.e. less then 0.008% of the pattern which the test wrote can be found.
Is this 0.008% important or anything else not covered by the RAM wipe?
See also this for leftovers in RAM that cannot be wiped by Tails implementation:
https://web.archive.org/web/20180628102336/https://mailman.boum.org/pipermail/tails-dev/2017-January/011134.html
Some things such as importantly, full disk encryption (FDE) is handled by the kernel. Probably user space couldn’t wipe the kernel memory holding the FDE key (unless there is a kernel API for that which would be related but separate).
On that view, wiping RAM might make sense for a live system such as Tails or Whonix / Kicksecure Host Live Mode (specifically when not using encrypted persistence) but would it also make sense for an FDE Whonix-Host or FDE Kicksecure-Host?
Without actual memory forensics we would not really know how severe any RAM wipe leftovers would be. If it includes the FDE key, then wiping the rest was worth little.
Even if RAM wipe by Linux kernel without firmware support would not be complete it could still per perfect and it could certainly better than anything doable in user space such as the Tails implementation. The kernel can certainly has the power to wipe any program from RAM since these are below the kernel in the hierarchy. And the kernel would not have to wipe things where the kernel knows that wiping these memory parts is not important because these are public anyhow, not private/secrets, or recoverable from the hard drive (assuming unencrypted /boot).
Any userspace to kernel memory has been greatly limited by security changes to Linux in recent years. A lot of attacks were basically about doing that to root the system. Unlikely that the memory erasure test can tell you anything about data remnance related to the kernel. This is done in more complicated way according to the cold boot attack papers.
You cannot trust third party firmware to do the wiping for you as they could be buggy or maliciously designed to not do a good job.
You should make a poll to see how many DRAM 2 systems are in use and or have non-removable batteries. Note that for the latter this isn’t guaranteed to aid data remnance, but may in some cases do unlike older RAM families which will always have slower data decay.
Summary: only a kernel solution makes sense and it is only worth pursuing if a substantial (20%+) number of systems need it.
Yes, we can’t wipe as much RAM without it but it seems complicated to implement.
The kernel already has a RAM wiping function, init_on_free which is what Tails uses. Tails just improves this and makes it wipe more by returning to the initramfs upon shutdown and unmounting the filesystem, thereby freeing more memory and having it wiped.
This essentially wipes all user space memory which is the most important part but leaves some kernel memory as the kernel cannot wipe itself hence why a complete implementation must be done at a lower level.
Avoiding all sidelines, keeping this simple, for my understanding and for the record and please correct me if I am wrong… Summary:
"cryptsetup close" of root device during shutdownis already implemented.
"cryptsetup close" of root device during shutdownis already implemented.iff your initrd/distro of choice do so. For the root disk it doesn’t matter what systemd does, it matters what the initrd/distro do. hence ping the maintainers of those.
Debian feature request:
Wipe LUKS Disk Encryption Key for Root Disk from RAM during Shutdown to defeat Cold Boot Attacks from Initial Ramdisk (initramfs-tools or dracut)
Control: severity -1 wishlist
Control: reassign -1 cryptsetup-initramfs
Control: block -1 by 778849Hi,
AFAICT dracut has dracut-shutdown(8) which you can extend at will, or
convince the maintainer to ship the required logic for everyone.
However Debian’s default initramfs, namely initramfs-tools(7) currently
has no interface to hook into at shutdown, and init doesn’t even hand
execution over to the initramfs during the shutdown phase (#778849).
When such an interface is available we can ship shutdown scripts into
cryptsetup-initramfs.cheers
--
Guilhem.
related:
Support restoring initrd on shutdown and pivoting into it (#778849)
Maybe a good reason for replacing initramfs-tools with dracut.
Debian dracut feature request:
Wipe LUKS Disk Encryption Key for Root Disk from RAM during Shutdown to defeat Cold Boot Attacks from Dracut Initramfs
dracut upstream feature request: