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
--8t9RHnE3ZwKMSgU+ Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable El d=C3=ADa domingo, julio 09, 2017 a las 10:33:40p. m. -0700, Doug Hardie = escribi=C3=B3: > > 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 ses= sion. > > 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. >=20 > The swap space was on this drive so it should be overwritten also. Physi= cal 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 s= ee 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 --=20 Matthias Apitz, =E2=9C=89 guru@unixarea.de, =E2=8C=82 http://www.unixarea.d= e/ =E2=98=8E +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=C3=B3 la Guerra. May 8, 1945: Who does not celebrate lost the War. --8t9RHnE3ZwKMSgU+ Content-Type: application/pgp-signature; name="signature.asc" -----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----- --8t9RHnE3ZwKMSgU+--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170710054116.GA2445>