writing to /dev/mem - after effects

[o5gmmob8]

Background:
I boot my machine up to memory with a squashfs image that gets removed once it is loaded. I decided to try writing to /dev/mem to see what would happen mainly because I would like to ensure the system is wiped and nobody could recover my data. The main purpose of this is when selling my inventory.

The machine I am testing on has 2 internal 2.5-in SATA drives with devices @ /dev/sda and /dev/sdb. Normally, when I connect my external drive, it shows up as /dev/sdc.

Process:
1. dd if=/dev/zero of=/dev/mem
2. shred /dev/mem

Both of above commands complained about writing to /dev/mem. However, it did let me write a little bit and wonder if it caused other issues.

For instance, I tried booting up today and my EFI entries for Gentoo were gone, but FreeBSD booted through the drive EFI entry.

Why did the system not auto discover the ESPs on both drives and attempt to boot either or at least show them as options?

This morning, to recover, I stuck in a USB thumbdrive and was able to boot to that, but then, what makes that work and not my external disk or the internal one?

Final Process:
1. rm -rf --no-preserve-root /
2. find /
/etc, /home were all empty, but /usr/bin /usr/sbin still had files and the system was mostly usable.

EDIT:
I revised the above post to make it clearer.

[pingtoo]

May I suggest you share your commands and surrounding environments when those commands executes.

In your descriptions there are too many different events and hard to follow orders so I cannot follow to understand what happen.

For example, you said you wish to test out write to /dev/mem use dd command. this is fine to test to learn however I don't follow is how is this affect storage system that cause boot failure. here it is unclear how/where in /dev/mem you did and how you did it.

[sublogic]

[o5gmmob8]

Yes, I'm aware.

Yes, it is suicidal, but I figured the system booted from memory, what could go wrong. I think the side effects were fairly mild, but who knows, it is probably more unpredictable than that. Perhaps next time it might be worse.

[Hu]

As sublogic already hints, the side effects may include writing to memory-mapped peripherals, some of which may be persistent. If I recall correctly, the infamous Linux e1000e corruption bug was because a write through a stale pointer was writing into part of the NIC's NVRAM. The wild write from accessing /dev/mem may have a similar result. As such, I am not surprised if any of your peripherals are misbehaving now. I would also contend that the original attempt is pointless. The true RAM that is exposed by /dev/mem will lose its value soon enough through simply halting the system. Any memory that can be wiped through /dev/mem, but which does not expire like that, probably should not be written at all.

I also think the rm was wrong and pointless. If you want to render the data unreachable, wipe the LUKS header so that the volume cannot be decrypted. (You did use encryption at the beginning, right?) If the volume is not encrypted, destroying its superblock has a decent chance of rendering the data inconvenient to retrieve. I will not say it is impossible, but trashing the superblock and other control information will be more effective, and easier, than unlinking all the files.

[o5gmmob8]

Yes, I agree about the LUKS header; however, the LUKS headers won't exist because I already physically removed the drive (USB thumbdrive) and the machine is running from RAM.

But yes, if I were leaving the drive in, I would remove the LUKS headers once the drive booted, and then reattach them as needed on start.