That said, I am really looking forward to Allan Jude's last patches hitting CURRENT, at which point I will rebuild that Laptop with UEFI booted, full disk encrypted root on ZFS without any unencrypted bootpartition.
There will still be the issue of the unencrypted bootloader that does the initial decryption to load the kernel, but that will likely end up an irrelevant attack vector compared to the Laptop's BIOS anyway...
For example on boot, it always prints that the boot device is invalid, since it gets confused by finding GPT partitioning without UEFI. Then you press enter and it happily continues to boot...
I never fully configured the UMTS modem in it I think, that entire class of hardware is just soul crushingly awful.
And as I am running CURRENT, every once in a while there is commit that throws i915kms into a suspend/resume tantrum (refusing to shut down, not coming back up). But since I do actually power down the laptop instead of suspending it, so that the disk encryption actually has a chance to help me out, I am not too bothered by it.
My use case for the laptop is mainly being a glorified ssh terminal multiplexer. It just needs to provide a comfortable, familiar runtime that I can navigate blindly at 3am, still partially asleep and without any coffee. All the tools need to be there, in the correct drawer, with the correct label and all the right marker labels on the man pages.
I tried running a Linux laptop/workstation combination at work since that is what our boxes predominantly run, but it just feels like running around in somebody else's slippers all day.
Sorry for oversharing.
Am I being silly, or could a hard drive full of random data be confused with a hard drive full of encrypted data by some member of the security services in the future? Would zeros not be a better bet?
The Debian installer attempts to write random data to the whole drive when you elect to encrypt the hard drive (except for the small /boot partition as mentioned in OA). I always quit out of that. My security needs are of the 'laptop left on bus' variety, not enterprise level.
What you might be thinking of is when decommissioning the drive after having encrypted it. At this point, I don't think it matters. I'm not sure drives come with all zeroed status from the manufacturer anyways.
Yeah, that would suck.
It seems likely that is either all zeroes, all ones, or uniform noise, but is that true, and if so, which is it? I would not know. Does anybody on HN?
Either way, both of those particular concerns are overkill for keeping a random thief from accessing your passwords.
Has this ever been demonstrated?
"The purpose of this paper was a categorical settlement to the controversy surrounding the misconceptions involving the belief that data can be recovered following a wipe procedure. This study has demonstrated that correctly wiped data cannot reasonably be retrieved even if it is of a small size or found only over small parts of the hard drive. Not even with the use of a MFM or other known methods. The belief that a tool can be developed to retrieve gigabytes or terabytes of information from a wiped drive is in error."
I was under the impression zeroing, well, didn't fully zero—specialized tools can recover the former bits. If you write a truly random stream to the drive, it's much harder to recover the former bit versus the new, random one. To my understanding it's the same reason why XORing one-time-pads are utterly effective as a form of encryption (and you can throw away the pad).
Important question, that makes me suffer in other *nix platforms: does anyone run a rig like this AND it work properly with sleep/hibernation and resume?
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.
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.
I believe Linux or BSD can do whatever you want, just be careful with what you want.
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.
No idea about Intel Rapid Start. I don't really deal with that side of the system.
(Sorry---I'd posted this to my now-defunct blog back in 2012.)
Apart from that, probably nobody needed it bad enough to sit down and write it so far.