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

On Mon, 22 Mar 2021 at 22:27, Maksim Fomin <[email protected]> wrote:

> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Monday, March 22, 2021 8:50 PM, Johnny Dahlberg <
> [email protected]> 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 -- [email protected]
To unsubscribe send an email to [email protected]