galtsev at kicp.uchicago.edu
Mon Jul 10 15:26:27 UTC 2017
On Mon, July 10, 2017 3:05 am, Steve O'Hara-Smith wrote:
> On Mon, 10 Jul 2017 07:22:28 +0200
> Matthias Apitz <guru at unixarea.de> wrote:
>> I do not think that this approach worked in the sense of overwriting all
>> blocks of the disk. While walking through at some point the kernel will
> I see no reason why it shouldn't, provided the dd process doing the
> work never needs to swap anything in (likely it's small and running a
> tight loop).
>> miss sectors of the disk, for example of memory mapped files of shared
>> libs of other running processes or swapped out memory to disk. And the
> The sectors are still there, just filled with 0s or random data the
> kernel will have no trouble reading them.
I believe, the kernel addresses swap not by addressing sectors on raw
device covering the whole physical drive, but as "relative sectors"
through swap partition device. If I'm right, once drive partition table is
gone reading swap will fail and panic kernel. And even though dd has small
footprint there maybe some process whose stuff was swapped out; and the
kernel does keep switching between processes. Of course, clever person
will kill everything. But the suggestion you made in another post: to make
tiny bootable system with dd, boot off it, and then overwrite everything
else is probably the only way to go in this remote situation. Which became
obvious to all of us after someone - YOU - suggested it. THANKS!
>> kernel will just crash or halt and you will notice that as terminating
> The kernel will not crash or halt, processes will if they have to
> page in corrupted data but that's all. Processes that don't page in
> anything will just carry on running - if they don't read the disc they'll
> never know it's been overwritten.
>> ssh session.
> Unless sshd has to page something in it won't crash.
>> Do not rely on the fact that the (sensitive) information on
>> the disk was overwritten.
> I see no reason to expect that the dd process won't finish clearing
> the disk and exit normally.
>> The only secure way is doing this from a system
>> running on some other disk and even this would allow to recover
>> information with forensic tools reading beside of the tracks. Only
>> physical destruction will help, for example burning the thing, as you
> Sure, but absent a motive to spend the money forensic data analysis
> costs writing 0s or random numbers over the whole drive will do fine. If
> you fear forensic analysis then use thermite.
> Steve O'Hara-Smith <steve at sohara.org>
> freebsd-questions at freebsd.org mailing list
> To unsubscribe, send any mail to
> "freebsd-questions-unsubscribe at freebsd.org"
Sr System Administrator
Department of Astronomy and Astrophysics
Kavli Institute for Cosmological Physics
University of Chicago
More information about the freebsd-questions