Bug 127378

Should /etc/init.d/random's functionality be moved before swapon in
rc.sysinit?  Or should swapon be moved to a script that runs after
/etc/init.d/random?  Or some other scheme?

Random should be moved to rc.sysinit/halt.

Shall I write this patch?  I should be able to get it done this weekend.

Nah, that part at least is done in CVS now.

So, the issue that I notice here is that encrypted swap and
suspend-to-disk (when it works/is supported) are not going to play
well together, at all.

Yes.  These two features are mutually exclusive by their current
definitions.  

However, encrypted swap is generally only a prerequisite to a safe
encrypted filesystem.  Would it make sense to use the filesystem's key
to encrypt swap as well (a persistent key vs. generating a session key
from /dev/random)?  I am not really up on suspend-to-disk.  Could
s-t-d work okay with a swap that is encrypted this way without much
modification?

Ie:

1.  write suspend data
2.  turn off
3.  turn on
4.  unlock swap using persistent swap key
5.  read suspend data

S-t-d simply adds the requirement that swap be consistent across
reboots.  Encrypted swap should be able to fulfill this requirement
with a persistent key.

Could someone provide a reason that a persistent swap key is dangerous?

Could someone explain why they would want to use encrypted swap
without any encrypted filesystems (that require persistent keys anyway)?

I've just setup encrypted swap on a Debian machine.  I put the 
following in /etc/crypttab: 
 
# <target device> <source device> <key file> <options> 
swap    /dev/hda1       /dev/random     swap 
 
Then the following in /etc/fstab: 
/dev/mapper/swap        none    swap    defaults        0 0 
 
 
The init script which runs this on Debian is /etc/init.d/cryptdisks, 
I have put a copy of it on http://www.coker.com.au/cryptdisks, it's 
in the Debian package cryptsetup available at the following URL: 
http://ftp.debian.org/pool/main/c/cryptsetup/ 
 
I think that the same method would work well in Fedora.  There is a 
current plan to implement swap with the "mount bu label" 
functionality.  But the same result can be obtained by swapping to 
an LV. 

The Debian work seems like a good base.  Here is what I did to get it
to work:

1.  Add chkconfig header to cryptdisks script and chkconfig --add it.

2.  Change /sbin/cryptsetup to /usr/bin/cryptsetup in cryptdisks
because the Fedora cryptsetup RPM installs cryptsetup in /usr/bin.

3.  Change the definition of OWNER in cryptdisks to OWNER=`ls -l $key
| awk '{ print $3 }'`.

4.  Create /etc/crypttab containing "swap /dev/hda3 /dev/urandom swap."

5.  Modify the swap record I had in /etc/fstab to "/dev/mapper/swap
swap ..."

6.  Comment out the swapon lines in rc.sysinit.

After these modifications I rebooted and performed a "swapon -a." 
Things seemed to work.

Some things that still seem to remain:

1.  The random  device still seems to be initialized pretty late in
the boot process (initscripts-7.59-1) -- S20random.  It needs to be
initialized before cryptdisks executes.

2.  Swapon -a is still executed by rc.sysinit before cryptdisks has a
chance to fire up the cryptography.

It seems thing number 1 in comment #8 is now fixed.  The initscripts
RPM change log says, "move random stuff to rc.sysinit/halt; move all
swap to after this.  prereq of bug #123278"

Thing number 2 in comment #8 still remains.  The rc.sysinit script
executes "swapon -a" before cryptdisks script has a chance to fire up
the cryptography.

Created attachment 103622 [details]
Patch that adds encrypted swap support to rc.sysinit

This patch integrates Debian's cryptdisks script into rc.sysinit and
init.d/halt.  This allows the proper ordering of the initializing the random
device, cryptodisks and swap.

The cryptodisks code must be run in two passes because:

/var/lib/random-seed must be available before the random device may be
initialized.  /var may be an encrypted so the cryptodisks code must be run
before /var is mounted.

* but *

The random device must be initialized before the cryptodisks code initializes
the swap partition.

To get around this chicken and egg problem, the cryptodisks code is executed
twice.

Cryptsetup is now properly built statically.  This was the last
remaining prerequisite for encrypted swap.

The patch against initscripts-7.77 still applies cleanly to
initscripts-7.99-1.

Incidentally a statically linked cryptsetup is not required for 
encrypted swap.  Rather it is required for an encrypted block device 
for the root file system. 

Is there enough interest in this to get it into Fedora Core 4?

I'd be very happy to see this (=everything Debian's cryptsetup package
adds to init scripts) in near future. 

Really useful feature in business environment.

Having been hacking in encrypted swap to rc.sysinit for
a while, I'd definitely like to see this feature.

A couple of concerns (I'm not sure how valid they are
with respect to what's proposed):

- For safety, before doing a mkswap, I think it would be
very good to check that the target is a swap partition.
If someone rearranges a partition on their hard drive the
device numbers may change, leading to clobbered data.

- After swapoff on shutdown, mkswap should be run on the
unencrypted partition to leave things in a clean state.
This might be necessary if, e.g., another OS uses this
partition as unencrypted swap and expects to be able to
mount it with a swapon.

These could be combined:
At startup, try to swapon /dev/hdaX (if not already listed
by swapon -s, otherwise just swapoff and skip the next step)
- if this succeeds, swapoff, cryptsetup /dev/mapper/hdaX,
mkswap /dev/mapper/hdaX and swapon
- if not, warn the user that /dev/hdaX doesn't appear to
be swap
At shutdown, swapoff, cryptsetup -remove, mkswap /dev/hdaX

Created attachment 111927 [details]
Patch that adds encrypted swap support to rc.sysinit

Now checks that a partition is a swap partition before initializing it.  Also
creates a  blank, plaintext swap on the partition before the system halts.

Created attachment 111930 [details]
Patch that adds encrypted swap support to rc.sysinit

This version uses swapon (instead of parted) to determine if a partition is a
swap partition.  Parted's print option is difficult because each line of its
output may have a different number of fields.

The patch assumes /etc/crypttab is present on all systems which probably will
not be the case, causing (probably harmless) errors. The same applies to the
mkinitrd patches at bug #124789. Other than that the encrypted swap patch seems
to be working ok.

Created attachment 113507 [details]
Patch that adds encrypted swap support to rc.sysinit

Now checks to see if /etc/crypttab exists before doing anything.

I've been using this successfully on my FC3 system since some time,
but for some reason, the update to kernel 2.6.12-1.1372_FC3 broke it:
the system blocks during the swap initialization.

The contents of my /etc/crypttab is as follows (because I didn't
want to repartition the entire disk, I've just added the second
swap space at the end of the disk, after shrinking the existing
partition):
swap    /dev/hda5       /dev/random     swap
swap1   /dev/hda7       /dev/random     swap

I've added some echo's in rc.sysinit to find out where it blocks,
and it seems to be in the cryptsetup invocation for the *second* swap
space: the first swap space is created successfully.

Any idea what is going wrong ?

Note that this is a fully up-to-date system (including the recent
mkinitrd package that seemed to be necessary to get this kernel
working under certain conditions).

Some further experimentation results:

- with the first swap space commented out in /etc/crypttab,
  the second one is created successfully.

- with the lines switched in /etc/crypttab, it is now the 
  /dev/hda5 one (which is now the second) that fails.

This indicates that the problem doesn't lie in the physical
properties of the swap spaces, but purely on the fact of invoking
cryptsetup for two different swap spaces.

Multiple swap partitions works fine for me when using the latest patch applied 
against initscripts-8.11.1-1.

My /etc/crypttab looks like:
swap   /dev/hda3   /dev/urandom   swap
swap1  /dev/hda9   /dev/urandom   swap

My /etc/fstab contains:
/dev/mapper/swap   swap   swap   defaults   0 0
/dev/mapper/swap1  swap   swap   defaults   0 0

Before rebooting after setting this up, I ensured that /dev/hda3 and /dev/hda9 
are formatted as swap.  My patch will refuse to created and encrypted swap 
partition unless the backing device is formatted as a regular swap partition.  
This is to provide a safety net against accidentally formatting a regular 
filesystem.

I changed my /etc/crypttab to use /dev/urandom (like you do) instead of
/dev/random, and then it works indeed.

There's probably not enough entropy available for /dev/random to work
reliably at this early stage in the boot process.  Should the patch protect
against the use of /dev/random ?  Although /dev/urandom is theoretically
less secure, it seems it has to be used here in some setups.

I no longer have the time to maintain/promote this patch.  Does anyone who is
watching this bug wish to take over?

Note that you can try to use util-lunux patch with cryptsetup support to
mount/swapon/swapoff:
 
  http://people.redhat.com/kzak/util-linux-cryptsetup/

For the reasons listed above, this may be a prerequisite for the safe use of 
David Zeuthen's recent work on encrypted volumes and the GNOME desktop.  See 
http://blog.fubar.dk/?p=64.

*** Bug 192558 has been marked as a duplicate of this bug. ***

Another proposed patch is in #192558.

BTW, if patch in #192558 "wins", some sanity checks should be made before
cryptsetup, e.g. checking whether device exists and type of partition has type
"swap" (82). Otherwise, after a typo, a partition can be going lost.

Created attachment 130227 [details]
Support encrypted swap and non-root filesystems

So, based on W. Michael's patch and Debian cryptsetup code, this is what I plan

to use;  the most important addition to the previous patches is LUKS support.

Anyone care to review the patch before it hits rawhide?

At least the swap section is working fine.

A note: On a PIII-450 /dev/random would be not a good choice, if a second swap
drive should also be encrypted. Looks like entropy is too low, cryptsetup hangs
until I hit some keystrokes.
Perhaps the support of /dev/random should show a note that this can consume some
time.

Applied in initscripts-8.35-1.  Thanks for the patches.

This extension isn't very reliable and causes at least 2 problems:

1) if 2 encrypted swap partitions are defined, something is going wrong with blkid:

# cat /etc/crypttab
swap-sda2       /dev/sda2       /dev/urandom    swap,cipher=blowfish
swap-sdb2       /dev/sdb2       /dev/urandom    swap,cipher=blowfish

 grep swap /etc/fstab
/dev/mapper/swap-sda2   swap                    swap    defaults        0 0
/dev/mapper/swap-sdb2   swap                    swap    defaults        0 0

# Start up swapping.
update_boot_stage RCswap
swappartitions=`blkid -t TYPE=swap -o device`     <--- strange result
echo $swappartitions
if [ x"$swappartitions" != x ]; then
        action $"Enabling local swap partitions: " swapon $swappartitions
fi
action $"Enabling /etc/fstab swaps: " swapon -a -e


This results in /dev/mapper/swap-sda2  /dev/mapper/swap-sdb2 /dev/sdb2

Executing this later, /dev/sdb2 disappears:
# blkid -t TYPE=swap -o device
/dev/mapper/swap-sda2
/dev/mapper/swap-sdb2

If I add a "sleep 5" in front of the blkid command, it works fine. Looks like
there is a check required whether mkswap's background (?) task is finished.


2) one time the system crashes before executing halt's mkswap after disabling
cryptsetup, encrypted swap will no longer work, normal swap also not, so system
has no longer any swap partitions.

Steps to reproduce: switch into single user mode, remount / ro and do a sysrq
sync,ro-mount,boot

Result:
/dev/sda2 is not a swap partition
/dev/sdb2 is not a swap partition


So entry neeeds to be reopen imho until this 2 issues are proper fixed.
As a manual workaround, administrator has to mkswap the encrypted partitions and
do a swapon -a

I have another suggestion, how about moving /var/lib/random-seed to another 
position, e.g. /.random-seed. This would make the code simplier and easier to 
understand. Or just seed /dev/urandom with 512 bytes of /dev/random, so 
that /var/lib/random-seed is not needed for the creation of swap / random keys 
or at all.

(In reply to comment #34)
> 1) if 2 encrypted swap partitions are defined, something is going wrong with
blkid:
> If I add a "sleep 5" in front of the blkid command, it works fine. Looks like
> there is a check required whether mkswap's background (?) task is finished.
blkid has a cache: if blkid.tab is less than 2 seconds old, it is used without
revalidating the cache.  The auto-swapon code is disabled by default in rawhide.

> 2) one time the system crashes before executing halt's mkswap after disabling
> cryptsetup, encrypted swap will no longer work, normal swap also not, so system
> has no longer any swap partitions.
Good point, fixed in CVS.  Thanks!

(In reply to comment #35)
> I have another suggestion, how about moving /var/lib/random-seed to another 
> position, e.g. /.random-seed. This would make the code simplier and easier to 
> understand.
I don't think this is worth special-case exceptions to FHS; actually I find
the separation of init_crypto more readable than just expanding it inline.

> Or just seed /dev/urandom with 512 bytes of /dev/random, so 
> that /var/lib/random-seed is not needed for the creation of swap / random keys 
> or at all.
That would defeat the point of random-seed entirely, the intent is to keep the
random generator seed across reboots.

*** Bug 190356 has been marked as a duplicate of this bug. ***