Bug 479579 - F10 LiveCD eats encrypted swap partitions
F10 LiveCD eats encrypted swap partitions
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: e2fsprogs (Show other bugs)
10
i386 Linux
low Severity medium
: ---
: ---
Assigned To: Eric Sandeen
Fedora Extras Quality Assurance
: Triaged
Depends On:
Blocks: F11Target
  Show dependency treegraph
 
Reported: 2009-01-11 12:16 EST by Mike C
Modified: 2013-01-10 00:00 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-12-18 02:34:36 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Mike C 2009-01-11 12:16:15 EST
Description of problem:Booting F10 LiveCD kills encrypted swap partition on existing system already installed to HD


Version-Release number of selected component (if applicable):initscripts-8.86-1.i386.rpm 


How reproducible:Every time


Steps to Reproduce:
1. On machine with encrypted swap partition boot F10 LiveCD
2. Work with LiveCD then reboot to main system from HD
3. Repeated requests for luks passphrase (actually prompt is "password:")
4. System eventually boots but system has no swap partition active.
  
Actual results: System does boot but without a swap partition since the liveCD had hosed the luks encryption on the swap area, and the main boot process then fails to find the luks mapped swap partition and so boots without a swap area.


Expected results: LiveCD should either recognise that the swap area is encrypted and request the passphrase, or continue to boot without using the swap partition, or at least give the user that option.  However, if the encrypted swap area is used correctly during liveCD boot, and mkswap not executed on the raw partition then the consequence may be to have a bad effect on the main system during a subsequent recovery from suspend if the main system had been suspended prior to running the liveCD, and then an attempt is made to come out of suspend.

Hence the better option is to not use the swap area if it is encrypted.
At the very minimum the user should be warned that continuing with the current boot could hose the swap area with the current rc.sysinit script.

Additional info:A beginner to Linux would be unlikely to recover from a hosed swap area in this scenario so the rc.sysinit file should be changed to accommodate this bad consequence, even though there will only be a small number of users who would hit this combination of circumstances.  However booting a liveCD that can hose your swap partition should not be allowed to happen - running a liveCD should be a safe way to do things.  Beyond a rawhide liveCD or possibly a pre-release liveCD one would not expect such bad things to happen with a released liveCD and this need to be fixed before any f11 liveCD is released.
Comment 1 john5342 2009-01-11 12:35:11 EST
This bug has been triaged
Comment 2 Jeremy Katz 2009-01-12 11:56:36 EST
This is a bug in libblkid.  We just ask for all swap devices and the encrypted swap dev should show up as being luks as opposed to the fact that it used to be swap/is swap underneath.

I know esandeen and I talked about it, but I'm not finding the other bug.
Comment 3 Karel Zak 2009-01-12 15:14:13 EST
(In reply to comment #2)
> This is a bug in libblkid.  We just ask for all swap devices and the encrypted
> swap dev should show up as being luks as opposed to the fact that it used to be
> swap/is swap underneath.

 Because the device is *valid* swap device and also *valid* luks device :-). See the bug referenced below. 

> I know esandeen and I talked about it, but I'm not finding the other bug.

Yeah, it sounds as a duplicate of bug 473514 - "LiveCD (on usb) ate an existing encrypted partition".
Comment 4 Eric Sandeen 2009-01-12 15:37:59 EST
Well crud.

There's also

Bug 468062 - Encrypted LV has mismatching UUID

So IIRC we had patches for both cryptsetup and for anaconda to zero out before creating the luks partition ... need to look and see if these both got committed in time for F10 I think.

And for swap made prior to that fix, then what ...
Comment 5 Eric Sandeen 2009-01-12 15:51:59 EST
Was the swap partition in question made prior to F10's release?   Overwriting swap w/ LUKS seems ok now:

[root@test tmp]# mkswap /dev/loop0
Setting up swapspace version 1, size = 131068 KiB
no label, UUID=f4d7a2ec-785b-4fd9-94cf-d73910bfaca0
[root@test tmp]# hexdump -C /dev/loop0  | head -n 10
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000400  01 00 00 00 ff 7f 00 00  00 00 00 00 f4 d7 a2 ec  |................|
00000410  78 5b 4f d9 94 cf d7 39  10 bf ac a0 00 00 00 00  |x[O....9........|
00000420  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000ff0  00 00 00 00 00 00 53 57  41 50 53 50 41 43 45 32  |......SWAPSPACE2|
00001000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
08000000
[root@test tmp]# cryptsetup luksFormat /dev/loop0

WARNING!
========
This will overwrite data on /dev/loop0 irrevocably.

Are you sure? (Type uppercase yes): YES
Enter LUKS passphrase: 
Verify passphrase: 
Command successful.
[root@test tmp]# hexdump -C /dev/loop0  | head -n 10
00000000  4c 55 4b 53 ba be 00 01  61 65 73 00 00 00 00 00  |LUKS....aes.....|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000020  00 00 00 00 00 00 00 00  63 62 63 2d 65 73 73 69  |........cbc-essi|
00000030  76 3a 73 68 61 32 35 36  00 00 00 00 00 00 00 00  |v:sha256........|
00000040  00 00 00 00 00 00 00 00  73 68 61 31 00 00 00 00  |........sha1....|
00000050  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000060  00 00 00 00 00 00 00 00  00 00 04 08 00 00 00 10  |................|
00000070  45 49 72 8e 34 41 37 cc  03 a8 5c 0e 31 97 de b9  |EIr.4A7...\.1...|
00000080  f6 52 1a 62 7e 4d ce 5d  7f af 12 c5 18 be d0 f6  |.R.b~M.]........|
00000090  00 25 a1 c1 26 52 b6 f7  29 92 10 37 d7 85 34 bc  |.%..&R..)..7..4.|
[root@test tmp]# blkid /dev/loop0
/dev/loop0: UUID="0e5658ca-71d4-4be6-a156-71db4104efb7" TYPE="crypt_LUKS" 

so it is properly identified by blkid and:

[root@test tmp]# hexdump -C -v /dev/loop0  | grep ^00000ff0
00000ff0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

the old swap signature is gone .... luks is doing the right thing now.

BUT going the other way:

[root@test tmp]# mkswap /dev/loop0
Setting up swapspace version 1, size = 131068 KiB
no label, UUID=c44cd15f-d554-4773-9505-7bc64332b128
[root@test tmp]# blkid /dev/loop0
/dev/loop0: UUID="0e5658ca-71d4-4be6-a156-71db4104efb7" TYPE="crypt_LUKS" 

argh, going the other way, mkswap is not zeroing out the LUKS header.   Sigh. (but I don't think that's relevant to this bug)
Comment 6 Mike C 2009-01-12 17:51:43 EST
In my system (as originally reported) the swap partition was created in a version of Fedora a few years ago but during the install of F10 I asked the installer to format and encrypt the existing swap partition (in this case /dev/sda6).

When I repaired the partition after using the liveCD I used cryptsetup create to make a new encrypted partition on /dev/sda6, and then mkswap to turn the encrypted partition into the swap area after luksOpen'ing it.

I am not near the machine in question at the moment but tomorrow evening I will get to the machine and run blkid on the partition as it stands and then report the result so you can see the TYPE if that would be helpful?
Comment 7 Mike C 2009-01-12 18:05:58 EST
I have now got a route into the original machine that generated this bz- and checked the swap partition. This was the /dev/sda6 swap partition that was overwritten by the livecd, and is now repaired.

[root@lapmike1 ~]# hexdump -C /dev/sda6  | head -n 10
00000000  4c 55 4b 53 ba be 00 01  61 65 73 00 00 00 00 00  |LUKS....aes.....|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000020  00 00 00 00 00 00 00 00  63 62 63 2d 65 73 73 69  |........cbc-essi|
00000030  76 3a 73 68 61 32 35 36  00 00 00 00 00 00 00 00  |v:sha256........|
00000040  00 00 00 00 00 00 00 00  73 68 61 31 00 00 00 00  |........sha1....|
00000050  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000060  00 00 00 00 00 00 00 00  00 00 04 08 00 00 00 10  |................|
00000070  c8 30 99 e5 37 c6 7d 10  1d 67 a8 84 3f 98 df 99  |.0..7.}..g..?...|
00000080  36 d3 1e b6 da 79 81 03  23 e2 17 56 c8 e1 3b f0  |6....y..#..V..;.|
00000090  28 39 2b 76 e0 d2 6f 1b  cc 19 a0 bb 66 89 8b 5c  |(9+v..o.....f..\|

[root@lapmike1 ~]# blkid /dev/sda6
/dev/sda6: UUID="f2013f34-3923-4087-b83f-4da73d06f31c" TYPE="crypt_LUKS" 

So the id is only showing the luks header.

The current swap partition was made on the mapped area and swapon -s confirms that this is operational.

The question I am not sure about is whether running a current rawhide liveCD (or f10 liveCD ) would overwrite this swap area again and cause the same problem? However I don't wish to run that test!

Nevertheless I hope the above is useful?
Comment 8 Jesse Keating 2009-04-13 20:52:49 EDT
I don't believe we'd delay the release for this, but we would take a fix.  Putting on the target.
Comment 9 Bug Zapper 2009-11-18 05:43:28 EST
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 10 Bug Zapper 2009-12-18 02:34:36 EST
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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