Yes. I use similar setup with Linux' LUKS disk encryption and suspend/resume with encrypted swap partition works.

You need to use initramfs with your kernel, so that kernel you boot from external drive is not alone but has some tools. Then you need to tell to your initramfs scripts to take care of encryption of your data and _swap_ partitions. Both dracut (redhat initramfs tool) and genkernel (gentoo initramfs tool) handle that.

With genkernel, this is what I currently have in /etc/default/grub. That's all I need, really.

GRUB_CMDLINE_LINUX="crypt_root=UUID=7e2c0396-7cc2-4468-9431-c85f81a4c9b2 root=UUID=d098a3ad-ff13-4a44-b4e6-d9e83cddd7ad crypt_swap=UUID=976f44a3-25c2-4869-b3b5-61808f3bc20d swap=UUID=5adcdf03-abaf-4cd3-8902-45228be2abe5 root_key=key swap_key=key root_keydev=UUID=d5878b0f-1997-467a-8f3b-65e78b16fb67 swap_keydev=UUID=d5878b0f-1997-467a-8f3b-65e78b16fb67 rootfstype=ext4 rootflags=rw,relatime,data=ordered resume=UUID=5adcdf03-abaf-4cd3-8902-45228be2abe5 "

With dracut, you want to look at options having "luks" in their names.

I am aware of how to do this on Linux. I do exactly as you subscribe.

But running the /boot on external USB seems to cause more issues than when I merely have /boot partition and a partition with LVM inside LUKS volume on the same physical disk.

I want to know if FreeBSD works that way, as I hear some FreeBSD on FreeBSDTalk and other podcasts say they have made big strides on laptop support (jokes abound with resume/sleep issues) on different laptops, but I am curious how far these improvements go.

External boot enables me to carry encryption key on it secretly so that I don't need to enter it manually. With on-machine unencrypted boot, you cannot do like that, because it's pointless. Anyway, another important issue is Evil Maid Attack. To recap, if you leave your device alone for a moment, an adversary may edit your bootpath (BIOS/EFI, or just your boot partition) to insert keylogger. Then, as long as you enter your key once, the game is over. BIOS/EFI hacking is not possible if you have trusted stuff setup properly. Hacking an unencrypted boot partition is just piece of cake.

I believe Linux or BSD can do whatever you want, just be careful with what you want.

Maybe I didn't just get your question right 616c, could you please elaborate what you are trying to achieve, if this is the case?

I leave the boot on the normal HDD and carry an sdcard with the key. I can also type the very long pass phrase and start the box though I could also make it key start only.

you can have /boot be part of luks/lvm so you don't have a separate unencrypted partition too

Works fine with suspend-to-RAM. FreeBSD doesn't have software suspend-to-disk support (and it's almost never implemented by the BIOS).

> FreeBSD doesn't have software suspend-to-disk support (and it's almost never implemented by the BIOS).

Linux has spoied me so bad I never noticed the former, and I am shocked by the latter.

Nice to get a response from a completely ignorant BSD and security notice, by the way. :-) I guess I could ego trip and say "how can I trust this user" but I suspect others will chuckle like me.

I'm having trouble understanding this comment. Possibly due to typos?

I think this person is impressed that the founder of Tarsnap would respond to the question of a novice.

Is BIOS support required for hibernation? I don't see why it's necessary; or rather I don't see why the firmware cares whether or not the operating system saved its state to swap before it powered the system off.

When ACPI S4 was first created, there were two versions: "S4OS", and "S4BIOS". In "S4BIOS", the dumping of RAM to disk is handled by the BIOS rather than the OS; this makes the implementation much easier since it means that the OS disk driver can be suspended rather than needing to figure out how to dump itself (and worse, restore itself) to/from disk.

Thanks for that, I had no idea! It sounds like I've been using S4OS with Linux. Do you know what the difference is between S4BIOS and Intel Rapid Start? They sound very similar to me. I'm wondering how the BIOS identifies, when it powers on, that it should resume and where it should read the contents of RAM from.

Yes, S4BIOS hasn't really been a thing for a long time -- once Windows supported S4OS (and didn't use S4BIOS even if it existed, since they quite reasonably didn't trust BIOS authors to get it right) all the BIOS authors said "this seems like a useless feature" and stopped providing it.

No idea about Intel Rapid Start. I don't really deal with that side of the system.