Comment by RetpolineDrama | Hacker News Reader

Comment by RetpolineDrama | Hacker News Reader

Parent Full thread

> but ironically, don't encrypt my root, so go figure

Oh man that takes me back. The last time I went down that rabbit hole was ~2015, I tried to implement a "fully encrypted" setup and started with Ubuntu (I know I know). Something something LUKS.

I spent ~2 days tinkering with it and never got it to work, something with the setup flow was totally broken if you also tried to encrypt root (or boot? idk like I said it's been _years_).

I also remember fun problems with grub. I was trying to dual-boot and the windows partition was using hardware-bitlocker (samsung SSD). Some kind of weird interaction was going on between grub, whatever the windows bootloader is called, and my motherboard's EFI I think. Anyways grub ended up fucking bitlocker up and I almost lost all my gaming saves. Had to use some kind of arcane recovery process to get back to being able to even _insert_ the key so the SSD would unlock and windows could continue booting.

Ended up saying screw it after a few days and just going back to windows for my gaming PC, vowing to never try dual-boot again.

Huh? I've been using LUKS for FDE (with unencrypted /boot) way before 2015, and it's never been a problem. Debian has offered an option to set it up during installation, and it was 100% smooth sailing from there.

More recently, you can even set up GRUB to ask you for the passphrase, so even /boot is encrypted, you only need a tiny 2MB partition at the front to hold the bootloader.

Well I remember getting completely stuck at one part and the cause was my samsung SSD's funny behavior in the "locked" state.

I had to set some kind of kernel flag or something (sorry, it's been years) to get it to ignore the drive until I unlocked it, as there was some kind of tight-loop where it would just keep trying to connect infinitely and not progress/fail/timeout.

I've been meaning to get back into linux again but it's going to be on a pristine/new machine.

You're definitely overcomplicating it. Security that's too hard to make use of isn't really accomplishing anything.

Well the work is in setting it up. Once it's working you just enter a password. I'm sure hardware FDE support in linux has come a long way since I last tried.

There shouldn't be that level of work required to set it up. The tools are lacking if it's not just a couple of commands or toggles to get a fully encrypted disk with a secure boot chain.

A couple times ago when I poked my head back in on my old pal, the Linux Desktop, to see how it was doing, I picked Ubuntu, and, because I'd gotten used to it on Mac, selected disk encryption at install.

This worked fine.

Months later (in this case I just left it connected to a TV and occasionally used it for gaming or whatever) I let it do an OS upgrade and it forgot how to read its disk when it rebooted. I spent maybe 30 minutes trying to fix it (former heavy Gentoo user, so I'm comfortable troubleshooting boot—among other—issues) without making any progress at all, then decided that was the end of that particular check-in with desktop linux. Maybe next time (spoiler: nope, though for different reasons. But maybe the next next time...)

I haven't tried encrypting a Linux root disk since.

> the windows partition was using hardware-bitlocker

That sounds way too exciting, even without that involved I keep my Windows install on its own disk.

I mean I love the idea right? Software FDE comes with a performance hit, as well as increased wear on the SSD.

With hardware FDE the data written to the raw flash is always encrypted, the AES key is just 0 by default. Macs work this way AFAIK. With "hardware bitlocker" you just change that key (on a fresh drive).

Full performance, better security. Seems awesome huh? Well being outside the happy-path when it comes to hardware configs on free software is just asking for trouble...

Reply on news.ycombinator.com