This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 127378 - [PATCH] Encrypted swap support
[PATCH] Encrypted swap support
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: initscripts (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Miloslav Trmač
: Reopened, Security
: 190356 192558 (view as bug list)
Depends On:
Blocks: 56698 FC6Target
  Show dependency treegraph
 
Reported: 2004-07-07 09:28 EDT by W. Michael Petullo
Modified: 2007-11-30 17:10 EST (History)
18 users (show)

See Also:
Fixed In Version: 8.38-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-08-02 20:39:55 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Patch that adds encrypted swap support to rc.sysinit (5.25 KB, patch)
2004-09-08 23:19 EDT, W. Michael Petullo
no flags Details | Diff
Patch that adds encrypted swap support to rc.sysinit (6.05 KB, patch)
2005-03-12 17:05 EST, W. Michael Petullo
no flags Details | Diff
Patch that adds encrypted swap support to rc.sysinit (6.14 KB, patch)
2005-03-12 22:01 EST, W. Michael Petullo
no flags Details | Diff
Patch that adds encrypted swap support to rc.sysinit (6.23 KB, patch)
2005-04-21 23:39 EDT, W. Michael Petullo
no flags Details | Diff
Support encrypted swap and non-root filesystems (5.68 KB, patch)
2006-05-30 09:22 EDT, Miloslav Trmač
no flags Details | Diff

  None (edit)
Description W. Michael Petullo 2004-07-07 09:28:19 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7)
Gecko/20040626 Firefox/0.8

Description of problem:
Encrypted swap support is a prerequisite for many encrypted disk
schemes.  This is because an encrypted disk is worthless if the data
it contains has been written to a plain-text swap partition.  Since
Fedora Core now contains dmcrypt, it should be possible to add
encrypted swap support.  Here are some notes on how this could be
accomplished:

1.  The randon number generator must be seeded before an encrypted
swap partition is enabled.  This is because a random session key must
be generated.  The key is not stored anywhere because swap does not
generally need to keep its state across reboots.

2.  The encrypted swap could be initialized using something like the
following:

/usr/bin/cryptsetup -d /dev/urandom create _dev_hda3 /dev/hda3
/sbin/mkswap /dev/mapper/_dev_hda3

3.  Adding an option to /etc/fstab could let the system know that a
swap partition should be encrypted:

/dev/hda3  swap  swap  cipher=aes  0 0

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
Notice that Fedora Core does not yet support encrypted swap out of the
box.
    

Additional info:
Comment 1 W. Michael Petullo 2004-07-07 16:09:56 EDT
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?
Comment 2 Bill Nottingham 2004-07-07 16:13:23 EDT
Random should be moved to rc.sysinit/halt.
Comment 3 W. Michael Petullo 2004-07-07 16:16:29 EDT
Shall I write this patch?  I should be able to get it done this weekend.
Comment 4 Bill Nottingham 2004-07-07 16:40:24 EDT
Nah, that part at least is done in CVS now.
Comment 5 Bill Nottingham 2004-08-05 12:51:00 EDT
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.
Comment 6 W. Michael Petullo 2004-08-05 13:19:56 EDT
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)?
Comment 7 Russell Coker 2004-08-11 00:55:34 EDT
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. 
Comment 8 W. Michael Petullo 2004-08-11 20:31:35 EDT
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.
Comment 9 W. Michael Petullo 2004-08-28 19:34:16 EDT
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.
Comment 10 W. Michael Petullo 2004-09-08 23:19:02 EDT
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.
Comment 11 W. Michael Petullo 2004-10-19 00:54:04 EDT
Cryptsetup is now properly built statically.  This was the last
remaining prerequisite for encrypted swap.
Comment 12 W. Michael Petullo 2004-11-28 11:41:14 EST
The patch against initscripts-7.77 still applies cleanly to
initscripts-7.99-1.
Comment 13 Russell Coker 2004-12-08 09:27:40 EST
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. 
Comment 14 W. Michael Petullo 2005-01-20 11:41:25 EST
Is there enough interest in this to get it into Fedora Core 4?
Comment 15 Toni Willberg 2005-02-16 16:09:52 EST
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.
Comment 16 Mike Breen 2005-02-28 14:00:49 EST
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
Comment 17 W. Michael Petullo 2005-03-12 17:05:40 EST
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.
Comment 18 W. Michael Petullo 2005-03-12 22:01:15 EST
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.
Comment 19 Panu Matilainen 2005-04-20 03:48:36 EDT
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.
Comment 20 W. Michael Petullo 2005-04-21 23:39:02 EDT
Created attachment 113507 [details]
Patch that adds encrypted swap support to rc.sysinit

Now checks to see if /etc/crypttab exists before doing anything.
Comment 21 Peter Verthez 2005-08-01 15:59:32 EDT
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).
Comment 22 Peter Verthez 2005-08-01 16:49:11 EDT
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.
Comment 23 W. Michael Petullo 2005-08-04 11:27:36 EDT
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.
Comment 24 Peter Verthez 2005-08-04 11:46:06 EDT
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.
Comment 25 W. Michael Petullo 2005-08-26 21:56:36 EDT
I no longer have the time to maintain/promote this patch.  Does anyone who is
watching this bug wish to take over?
Comment 26 Karel Zak 2005-10-13 08:41:45 EDT
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/
Comment 27 W. Michael Petullo 2006-02-23 11:03:02 EST
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.
Comment 28 Miloslav Trmač 2006-05-25 11:04:03 EDT
*** Bug 192558 has been marked as a duplicate of this bug. ***
Comment 29 Miloslav Trmač 2006-05-25 11:06:21 EDT
Another proposed patch is in #192558.
Comment 30 Peter Bieringer 2006-05-25 12:25:44 EDT
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.
Comment 31 Miloslav Trmač 2006-05-30 09:22:45 EDT
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?
Comment 32 Peter Bieringer 2006-06-03 08:03:42 EDT
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.
Comment 33 Miloslav Trmač 2006-06-14 09:54:20 EDT
Applied in initscripts-8.35-1.  Thanks for the patches.
Comment 34 Peter Bieringer 2006-07-12 18:32:58 EDT
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
Comment 35 Till Maas 2006-07-12 19:05:04 EDT
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.
Comment 36 Miloslav Trmač 2006-07-24 15:47:33 EDT
(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!
Comment 37 Miloslav Trmač 2006-07-24 15:53:02 EDT
(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.
Comment 38 Miloslav Trmač 2006-07-29 18:58:08 EDT
*** Bug 190356 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.