lkml.org 
[lkml]   [1998]   [Dec]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Unswappable memory needed is user space
On Tue, 8 Dec 1998, David F. Newman wrote:

> On Tue, 8 Dec 1998, Richard B. Johnson wrote:
>
> > On Tue, 8 Dec 1998 christophe.leroy5@capway.com wrote:
> >
> > This doesn't mean that the null-fill will actually get to the physical
> > device. Further, filling with a known data-type will allow the data
> > to be recovered by hardware means.
>
> I was always under the impression that it was ok if you first
> write all 0s and then all 1s and then 0s and 1s and then 1s and
> 0s over the existing data. Although you don't know if the data
> has been moved around on the filesystem because of disk optimizing.

The hardware recovery of data works this way.

As the disk-drive warms up, it's geometry changes. Data that was
written when the drive was cold will be on some place on a track,
maybe on the center, maybe on an edge. When the drive is at its
final temperature, new data will be written in a slightly different
place on the track.

If you use a special head, designed to read different areas of the
same track, it is possible to read data that was written during
different temperatures. This is how you recover overwritten data.
It makes no difference what the data pattern was during the last
write. However, if you write a similar sequence like 0xAA or
0x55 or 0x00 or 0xFF over the whole sector/track, it is easy to
determine where the latest data is, which is not where the
data you want to recover is. This makes it easier to find the
old data, which is not what you want to do.
Therefore you should write a pseudo-random sequence, AND you
should keep your "secure" drive spun up all the while so it
remains at its final temperature. This is the best guarantee
against anyone recovering your erased/overwritten data.

> I suppose you could use an encrypted file system. I don't know
> if you can do that on Linux, however.
>

You can use mlock() for your buffers. However, your program and
any static and local data, perhaps containing your key can be
swapped out (You got a telephone call, let the machine set idle
for a few minutes and somebody logged in and ran a LARGE program).

I would just turn OFF swapping. The LARGE program fails to allocate
buffers and becomes a small program.

> > > My problem is that if the crypting process is swapped out during
> > > crypting, one could be able to recover parts of uncrypted file
> > > in swap partition.
> > >
>
> Having the most secure system possible won't keep the Feds from
> breaking in and confiscating your system. They'll get your
> data without the root password. Trust No One!!!!!
>

If the data existed only in RAM its pretty well gone after a few
minutes with the power off.

Cheers,
Dick Johnson
***** FILE SYSTEM WAS MODIFIED *****
Penguin : Linux version 2.1.131 on an i686 machine (400.59 BogoMips).
Warning : It's hard to remain at the trailing edge of technology.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:46    [from the cache]
©2003-2011 Jasper Spaans