What happens when I use 'dd' to overwrite the disk from which Ubuntu is running?

Actually, the filesystem is still mounted, and some writes are buffered meaning they are still in RAM waiting to be written to the disk. Let's say dd correctly overwrites everything, and just behind it the buffers are getting flushed and some potentially sensitive data is getting written back to the disk. So no, this is not a secure way of wiping a disk.

You can avoid this issue by first remounting in read-only mode the root filesystem and any other filesystems that are on the disk (or unmounting them completely, but you won't be able to with the root file system), and then, no more writes should be allowed on the filesystems at all (so no buffers to flush) so your command should be safe now, even though it's still a bad idea in case of panic because it takes a long time.

If you want to have some sort of panic delete feature, I suggest encrypting your disk with LUKS (the Ubuntu installer can do that) and then following my answer over on Security Stack Exchange. This involves wiping the cryptheader which is only 2MBs in size and that takes less than a second to overwrite. Then restart the system and the disk encryption keys will be gone from memory, with no ways to restore them since the cryptheader itself is gone as well.

I sacrificed a VM using a slightly more advanced usage of dd borrowed and slightly modified from the Arch Wiki pages.

First install a nice progress meter:

sudo apt-get install pv

And then run the 'enhanced' dd command

sudo openssl enc -aes-256-ctr -pass pass:"$(dd if=/dev/urandom bs=128 count=1 2>/dev/null \
| base64)" -nosalt </dev/zero \
| pv -bartpes "$(sudo blockdev --getsize64 /dev/sda)" \
| sudo dd bs=64K of=/dev/sda

This will leave the disk filled with AES ciphertext. A complete and secure disk wipe? Probably better than your own dd example but nothing is completely safe or guaranteed...

And you owe me one VM :)

References:

• Arch: Securely wipe disk
• Arch: dd - Advanced Example

Short answer: it'll do roughly what you want and then nothing will work. Using dd you're operating at a level below the filesystem which means that any constraints which would apply there are no longer relevant (this doesn't mean that the kernel couldn't prevent you doing this - but it doesn't). Some content from the filesystem is already in memory, for example the kernel and the dd program itself, and some will be in cache. There is a possibility that if the system is in multi-user mode some files may be written back while the dd is in progress, assuming that they actually have changed, and if you're under memory pressure some pages from there may also get swapped out (they should be encrypted and thus unusable after reboot).

Most commands you'd issue following this - including reboot - would not be in the cache and so would not work. So if you're in single user mode, it'll do extremely well, if you're in multiuser mode it'll wipe the vast majority of data. Ideally you should do it booted from some other medium (even stopping on the initrd perhaps) so that you can be sure where all the writes are coming from.

If you want a secure wipe, this won't do the job because there will still be some traces of the original data remaining if you just zero it. Typically you'd want up to three random writes, which would mean copying from /dev/urandom instead of /dev/zero - much slower but safer. Some may suggest that you use /dev/random which is the device for "pure" random data - no pseudo-random - but for this purpose the chance of somebody managing to crack the PRNG seed and successfully mask out the data is essentially negligible.

If you're really paranoid, you need to throw the storage device into a furnace so that it demagnetises/discharges.

It will as it did in your VM wipe the disk and render your system unusable.

However if you have a sort of 'panic deletion' in mind dd might not be fast enough for that and I'm not sure if there are faster commands or programs providing it in that case.