Subject: Re: zero'd swap & encrypted swap
To: None <>
From: Lord Isildur <>
List: tech-kern
Date: 06/04/2001 18:48:29
On Mon, 4 Jun 2001, Greg A. Woods wrote:

> In fact it doesn't seem obvious to me that any CPU can be "wasted" while
> the system is swapping -- certainly there is time where the CPU is idle
> waiting for the I/O to complete, but that's after the I/O request has
> been sent, not before!  ;-) [or conversely after the I/O is done and the
> data's available].  If swap operations are always multiple I/Os then I
> guess the encryption delay might only be before the first operation on
> write and after the last on read, but is that _often_ the case?

actually, that time is spent on other processes if there are any. the 
time is only really wasted if theres only one process running. because 
this time is _not_ going to waste, to consume it is _not_ free. 

> and then you expose the machine physically (or it's something like a
> laptop -- in which case obviously your filesystems are encrypted with
> some long-living key, right? :-), then you might risk some exposure of
> recently used data, but is encrypted swap really worth it?  I guess it
> depends on what kind of data you work with on an already physically
> exposed machine!  :-)

the risk of physical compromise is about the only reason to encrypt it, i 
think (or sero it), because that thwarts the attempts to recover data 
even in the case of physical access. While the systm is running, there should
be no reason to encrypt it on account of a malicious user, because if 
that user could get to swap then he certainly could compromise other 
privileged aspects of the system and circumvent any encryption being done 
in the first place. having nonvolatile storage encrypted all the time 
protects you from physiucal compromise at any time , including the 
drastic 'bad guys rush in unexcpectedly and forcefully take the machine' 
scenario. In this case, the encryption shoudl be to block devices in general
and not swap in specific, and activated or disable don a device by device 
basis, and the keys not be stored anywhere in the system except in 
nonpaged space in the kernel while running. feed the keys in from outside
the box at boot time, either by hand, over a serial line, etc, if you really
want to be secure about it. generally speaking, anything less than complete
will not be very secure against this attack, and pretty much any lesser 
attack will either not involve this kind of risk, or else presupposes a 
different kind of risk which makes this kind of protection moot.