Re: What to encrypt and why (was: Using dm-crypt: whole disk encryption

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On Mon, 22 Mar 2021 at 22:27, Maksim Fomin <maxim@xxxxxxxxx> wrote:
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday, March 22, 2021 8:50 PM, Johnny Dahlberg <svartchimpans@xxxxxxxxx> wrote:

As for whether to use UEFI boot or not: Yes. Use it. It's way more robust than MBR boot methods. Don't be afraid to research what systemd-boot is, if you want to know. Or just enable UEFI in your BIOS (it's most likely on by default on your new laptop) and just install the OS and it'll automatically use UEFI.

As for what to encrypt:

/boot/efi = No. It must be unencrypted to be able to boot. But it only contains your bootloader, kernel and initramfs which is what sets up the decryption environment.

/ (root) = Yes. All of it will be encrypted with your passphrase.

As for having a separate /home partition: Don't bother. It makes no sense at all and just creates hassle when you inevitably run out of space in either / or /home. There are no benefits to a separate home directory. None. People think it makes OS reinstalls or distro hopping easier. Nope it doesn't. If you have a unified partition, you simply have to boot any random liveCD and delete everything except the /home folder, and then install your OS on the same partition without formatting it, and voila you've kept /home without tediously separating it.

If you wanna check out the distro I recommended in the longer answer about full disk encryption, you even have a "Refresh Install" feature in the installer, which deletes everything except /home and reinstalls the OS. That's another fantastically easy option. :-)


-- Johnny

2. Having separate /home partition has several benefits: if root fs is damaged, the home partition is left intact. Also, depending on fs type, its configuration and partition size io operations can be faster on smaller partitons than on a big one.
3. There are such tools like lvm or fs subvolumes which make the choice between single or separate partition redudant. For example, lvm alows to share single partition space for several virtual partitions (they are fs independent - if one fs is damaged, other are still ok). Some fs allow to have subvolumes which also share space (but they are fs dependent, so if fs is damaged all its subvolumes are also damaged).


 Hi Maksim! :-)

"if root fs is damaged, the home partition is left intact."

I disagree. If we're talking general filesystem corruption, that's equally likely to happen to the home partition. And in both cases it's just minor stuff like corruption from a loss of power during write. All of which is fixable with a simple filesystem check/repair command.

The other kind of corruption, which is physical corruption of the storage medium, is also equally likely to happen to *any* partition.

The final kind, which is software induced data loss such as "rm -rf /", will likewise destroy the home partition too.

So corruption isn't a reason to separate partitions.

"depending on fs type, its configuration and partition size io operations can be faster on smaller partitons than on a big one."

What are you referring to here? The speed of formatting a brand new filesystem? That's a do-it-once-and-keep-it-for-years operation and I would think it's silly to worry about that inital formatting. Which usually takes mere seconds in quick format mode. It's not a reason to separate partitions.

"There are such tools like lvm or fs subvolumes which make the choice between single or separate partition redudant."

That is a really good point. LVM thin provisioning lets several volumes have a shared pool of storage, which would make it possible to separate home and root without defining fixed sizes for each. Although I still don't see the point compared to the process I described. Since you can always rely on a filesystem check keeping the health of your filesystem, it doesn't matter if your /home filesystem is separate or shared with the rest of /. It's not more safe.

But LVM thin provisioning is definitely the route I would choose if I had to separate them. Performance is probably pretty good, since LVM allocates chunks of 4 MiB by default, so there shouldn't be any massive fragmentation by doing that.

Anyway, good luck with your new system, Ken!


Best Regards,

-- Johnny
_______________________________________________
dm-crypt mailing list -- dm-crypt@xxxxxxxx
To unsubscribe send an email to dm-crypt-leave@xxxxxxxx

[Index of Archives]     [Device Mapper Devel]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux