Date: Mon, 10 Jul 2017 07:41:16 +0200 From: Matthias Apitz <guru@unixarea.de> To: Doug Hardie <doug@sermon-archive.info> Cc: "freebsd-questions@freebsd.org Questions" <freebsd-questions@freebsd.org>, galtsev@kicp.uchicago.edu Subject: Re: Unusual Question Message-ID: <20170710054116.GA2445@c720-r314251> In-Reply-To: <5156E6FD-03AE-4244-B3AB-32007439AD20@mail.sermon-archive.info> References: <888578F8-AD68-4993-823C-152789F3C929@mail.sermon-archive.info> <52627.76.193.16.95.1499645892.squirrel@cosmo.uchicago.edu> <BF16E1CF-A889-4734-981E-2B68115FCD3C@mail.sermon-archive.info> <20170710052228.GA2338@c720-r314251> <5156E6FD-03AE-4244-B3AB-32007439AD20@mail.sermon-archive.info>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] El día domingo, julio 09, 2017 a las 10:33:40p. m. -0700, Doug Hardie escribió: > > 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 > > 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 kernel > > will just crash or halt and you will notice that as terminating ssh session. > > Do not rely on the fact that the (sensitive) information on the disk was > > overwritten. 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 said. > > The swap space was on this drive so it should be overwritten also. Physical memory will go when the power goes off. It would be nice to be able to get the drive back and see just how much was overwritten, but that is not possible. I don't see why dd would not run to completion. The first test I ran it reported that it had cleared over 300 GB on a 500 GB drive. I may see if I can setup another system here and try that where I can monitor and test the result. Doug, you missed my point. Your dd proc will overwrite at some point the swaped-out pages and/or text segments which have been memory mapped by the kernel. The kernel will miss them and crash and so you have only overwritten a (maybe small) part of the disk. matthias -- Matthias Apitz, ✉ guru@unixarea.de, ⌂ http://www.unixarea.de/ ☎ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub 8. Mai 1945: Wer nicht feiert hat den Krieg verloren. 8 de mayo de 1945: Quien no festeja perdió la Guerra. May 8, 1945: Who does not celebrate lost the War. [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEXmn7rBYYViyzy/vBR8z35Hb+nREFAlljE3kACgkQR8z35Hb+ nRFibg//cX7ujNGvdhubkGbQ2O0WqHS6KjDqqbb1wqoUqYCBpvp75KpeuD2lvKYB Kj28NGUBFnECly+JStN1QBJToyCAx0ckCnkHUUgt4XsPt22x4Z0IIbkYfXQFAJCg Ogl4nv9iW69YeZmjAK1pgSKFJdpEpVXGpJUZvJUK9IU2eA0EdV8U0pGtU0TlfXpF D5jvFq8nhiARjL7DeCq0tMgfE423i/6TixFMgGP/310wW99aMCqHz/7eq2GuEAjT JFZMnqQh7x8nbrnLlsAV+ivEDWonUhVuS4DlSvrAUkqunWtjGDfWi86IYCnSm+TN nRaVV0tut/yGbT1C/PnojBEyg4GIS/KKR/RRj51BSo06WBgK2mumDNzIw3Gc/yu8 6TP5R7gNpx9Ssslnd14Qj2WfzxI6+OT9miIY3gzXWB4rsFZWJiaCTkfJHrun7rGd brKYa+LJDnEhDPzREBWF7ZsCXOszLLU55LLx0ffNCbaoSqCf+PuJ3oKYDf4Srkj8 MYBUZz+z6uAGx3dCV4BDuW6ag962xoSOmFKPuduE4U1hLrTxuvBbIOgkBmafiVn9 nO2ghViSqSgP8B2B2tfCy9WI/IguW8aHa9alWqGh0zY0h3gB4XwjB6CYpYH4jeTO /lNCD14cRGKAPA1iju6375rVDd6OgCYYLCt3vxncSb1rJOo1Eho= =nS1x -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170710054116.GA2445>