Re: The disappearing sys_call_table export.

[Jesse Pollard <jesse@cats-chateau.net>]

On Monday 12 May 2003 17:57, Yoav Weiss wrote:
> On Mon, 12 May 2003 17:51:25 EDT, Chuck Ebbert said:
> > > man dd ?
> >
> >   "That can be done manually" does not get you the check mark in
> > the list of features.  Management wants idiot-resistant security.
>
> It has nothing to do with idiot-resistance.  Why should this multi-write
> operation be done in kernel ?  mkswap is a usermode program.  mkfs is a
> usermode program.  If you want to have a wipeswap script that copies a
> chunk of your /dev/zero to the swap, it should also be in usermode.  Just
> run it in wherever rc file you use to swapoff.
>
> However, it'll just give you false sense of security.  First of all, its
> hardware dependent.  Second, it won't get wipe in case of a crash (which
> is likely to happen when They come to take your disk).

It is also not a valid wipe either.

This particular object reuse assumes the hardware is in a secured area. If it
is in a secured area then you don't need to wipe it. It remains completely 
under the systems control (even during a crash and reboot). The interval 
between crash and reboot is covered by the requirement to be in a secured 
area. As long as the system doesn't reallocate the data to another process
everything is acceptable. The only condition is that the area is erased
BEFORE allocation. And if it is erased by the NEW data, then the old data
is gone. In the case of swap, the page is first zeroed (given to process as
a demand zero, or preloaded with the users data), then written to swap and
allocated. This last twostep is the only question - is it written first, then
allocated, or allocated and written?

> Until linux gets a real encrypted swap (the kind OpenBSD implements), you
> can settle for encrypting your whole swap with one random key that gets
> lost on reboot.  Encrypted loop dev with a key from /dev/random easily
> gives you that.

Ahhh not a good idea if you want job restart or suspend/resume. And large 
systems DO want a job restart... as do laptops. During suspension you can
do anything to the disk (as in remove it, insert in another system, read
it, then put it back ...)

Such low level object reuse is not viable. This is from the same book that
states it must be overwritten 3-5 times (something in that range). The full
overhead reduces throughput to about 25-50% of total capacity. The object
reuse erasure applies to memory as well.

You also cannot guarantee erasure on disk errors either. The bad sectors are
ignored, and remapped to alternate sectors - the data is not deleted. Full
object reuse was written long before disks were performing this action. It
assumes the remapping is done by the OS, and hence, is also to overwrite the
bad sectors as well.