How to use GELI suspend/resume?

[MasterOne]

While examining the procedure to perform an installation with full harddisk encryption, I stumbled over the interesting feature of geli to suspend and resume encrypted devices, which makes it ideal on a laptop/netbook when using suspend-to-RAM:

Suspend device by waiting for all inflight request to finish, clearing all sensitive informations (like keys) from the kernel memory and blocking all further I/O requests until the resume subcommand is executed. This functionality is useful for eg. laptops - when one wants to suspend a laptop, one does not want to leave encrypted device attached. Instead of closing all files and directories opened from a file system placed on an encrypted device, unmounting the file system and detaching the device, the suspend subcommand can be used.

Unfortunately there seems to be catch with resume when using full harddisk encryption:

The caller must ensure that executing this subcommand won't try to access suspended device, which will lead to a deadlock. For example suspending device, which contains file system where the geli utility is stored is bad idea.

Any idea if there is any way to overcome that issue? Maybe copy the geli utility to the unencrypted /boot partition and call from there, or is there no way at all to use GELI suspend/resume with full harddisk encryption?

The GELI manpage shows the following example:

Suspend all geli devices, suspend a laptop, then resume devices one by one after resuming a laptop:

# geli suspend -a
# zzz
<resume your laptop>
# geli resume -p -k keyfile gpt/secret
# geli resume gpt/private
Enter passphrase:

But what exactly happens with processes trying to access the encrypted harddisk after <resume your laptop> BEFORE the encrypted GELI device(s) are resumed? The manpage only tells:

Any access to the encrypted device will be blocked until the keys are recovered through resume subcommand, thus there is no need to close nor unmount anything.

If it's just not possible to have both (full harddisk encryption / encrypted root AND geli suspend/resume), what would be the safest way to protect all your data AND use geli suspend/resume on a laptop/netbook then? I mean, which filesystems to put in separate partitions for encryption to have it all covered?

Another related issue:

The suspend subcommand does not work with devices created with the onetime subcommand.

So would it be a bad idea to use onetime encryption for the swap partition in matters of using suspend-to-RAM? Will there be any harm to put the laptop/netbook into suspend mode without suspending the encrypted swap partition first? Which approach for encrypting swap would be the most appropriate to use otherwise in conjunction with suspend-to-RAM?

 

[fonz]

Maybe copy the geli utility to the unencrypted /boot partition and call from there, or is there no way at all to use GELI suspend/resume with full harddisk encryption?

It's probably going to be difficult. /sbin/geli calls things in /lib, among others. And even if you get it to compile statically, it's probably going to need e.g. /dev/ entries and such. I'm inclined to say it's going to be pretty tricky to get suspend/resume and encrypted root to play nice together, if at all possible.

I mean, which filesystems to put in separate partitions for encryption to have it all covered?

If you mean: "Which filesystems can be expected to contain sensitive data and therefore need to be encrypted?", I'm inclined to say the following:

• /home;
• /tmp;
• /var;
• Perhaps a few files in /etc, most notably /etc/wpa_supplicant.conf.

If you're using lots of partitions you can perhaps limit encryption to parts of /var (I'd say most notably /var/log, /var/crash and /var/mail if the latter is being used). Also note that putting /etc in a seperate partition is generally a bad idea, to say the least.

Hopefully, others can comment further on this. And if I misunderstood the question, forget I said anything.

So would it be a bad idea to use onetime encryption for the swap partition in matters of using suspend-to-RAM?
[snip]
Which approach for encrypting swap would be the most appropriate to use otherwise in conjunction with suspend-to-RAM?

I've been pondering the following: if a swap partition resides inside a partitioned geli container (e.g. /dev/ad1s1.elib or something), does it still need onetime encryption on top of that? I'd imagine it's already being encrypted, so it doesn't. In that case perhaps it's at least worth trying.

Hopefully someone else can weigh in on this.

Fonz

 

[vermaden]

How to use GELI suspend/resume?

I use ZFS on GELI and suspend/resume works without any other settings/tweaks.

 

[MasterOne]

Yes, it pretty much looks like root encryption is out of question if GELI suspend/resume is to be used.

So keeping it as simple as possible, it would mean to have the following partition split-up

/
/home
/var
/tmp
swap

which brings up the problem again, how much space to give to each partition (nearly impossible decision to make for me for machines with 16GB / 32GB / 60GB / 160GB harddisks, as I have no clue about those partition requirements).

And it still would expose /root and /etc being unencrypted, so this is another bad trade-off.

I use ZFS on GELI and suspend/resume works without any other settings/tweaks.

You are taking about computer suspend/resume, but this matter is about GELI suspend/resume, which is a pretty cool feature, because with it you can suspend GELI devices before suspending the computer, requiring to resume those GELI devices with entering the passphrase again after resuming the computer.

Not using GELI suspend/resume means, if you suspend your computer and it gets stolen, the thief has full access to your unencrypted data if he resumes the computer, which can be a major problem, because what for did you encrypt in the first place?

 

[vermaden]

You are taking about computer suspend/resume, but this matter is about GELI suspend/resume

Now I got it, thanks for explanation