Is RAM Wipe possible inside Whonix?


I am pretty new here compared to most of you, and probably not half as knowledgeable, but still I’m trying to help out best I can.

For the past two weeks or so I have been messing around with Whonix 14 trying to implement different methods of RAM erasure that I have been able to locate.

I found a guideline on Tails website in their design subject about how they go about it on a page titled “Memory Erasure”. I’m still working on trying to implement that in Whonix, but I have heard of some accomplishing this task on Debian so I feel it could be possible. If I am wrong about that I would love to know why cause I have been working quite hard at implementing it.

Aside from that I have also tried tools like sdmem which was quite easy to use as a solution on shutdown, but I have heard it to not be as effective as one would want. I am also checking out memtest86 as a possible solution, but still I fear that may suffer the same problems.

Has anyone else been working on this feature mostly for the live system that could point me in the right direction, or simply tell me if I am wasting my time. I just think this would be a wonderful feature to be available on Whonix. An amnesiac system with the added security provided by isolation Could really change things. A lot I have spoken with about this idea are quite excited by it so I have been working hard to make it possible, I just don’t know if it is indeed possible or not.

Tails Documentation



If you can make it work on Debian, that solution will also work for Whonix.



https://tails.boum.org/contribute/design/memory_erasure/ sounds like its working. Documentation looks very good.

Just needs to be properly Debian packaged. Looks doable.

Could you package it please? There are a ton of examples in Whonix source code. Packaging using genmkfile is simpler than usual packaging.


Please remove any /local from file paths.

Only the .c file could be a bit more difficult to package. But that one looks only required for “USB boot medium is unplugged or boot DVD is ejected”. We could compile it perhaps using the postinst method.

Adding a systemd unit file simple example commit: https://github.com/troubadoour/tor-control-panel/commit/0a4fc8a90f4f916ee2091d84d7da24690cce0d36
(add dh-systemd to Build-Depends: in debian/control;
use dh $@ --with systemd;
add systemd unit file to lib/systemd/system/name.service)


But I thought with DRAM3 and beyond the danger of data lurking in memory after a shutdown was no longer a problem since it forgets it with a couple of seconds


I am terribly sorry about the delay in reply Patrick, there were some personal issues that needed tended to.

I checked out the code, and gave it a test run on Debian. It works amazingly. This is exactly what I had been trying to do but I hadn’t been able get it working right, but this code is well awesome to say the least.

I would be more than happy to work on packaging it for you if it will help. It may not be the most important feature in the eyes of a lot of people, but I say if the data can be thoroughly wiped very fast upon shutdown without causing issue I see no reason why it shouldn’t be.


The USB feature doesn’t apply too much to us so I see what you are saying, but it would be neat to have the option to set a drive as a key of sorts that would initiate the shut down the machines when removed like with the USBKill program. I’ll look closer at it shortly. If it won’t be doable right now I’ll package the wipe for shutdown.

I think something that would really be something would be if we could get a wipe function working for Qubes with the live system. I guess that’s something to worry about in the future, for now I’ll just focus on the package for Debian.


By all means, I find this very important to have a swell. Would love to have any kind of enhancement packaged and then being picked up by packages.debian.org. From there, future iteration enhancements are doable over time.