[bug#49654] [PATCH] doc: Add full disc encryption guide to the cookbook

[Joshua Branson]

Giovanni Biscuolo <g@xelera.eu> writes:

> Hello Joshua and Raghav,
>
> thank you for your guide!  I have just a couple of comments.
>
> Joshua Branson via Guix-patches via <guix-patches@gnu.org> writes:
>
>> From: Joshua Branson <jbranso AT gnucode.me>
>>
>> The original guide was written by Raghav Gururajan <rg@raghavgururajan.name>
>> and edited by Joshua Branson <jbranso@dismail.de>.
>>
>> * doc/guix-cookbook.texi (System Configuration): New section of full disc
>> encryption via libreboot.
>> ---
>>  doc/guix-cookbook.texi | 724 +++++++++++++++++++++++++++++++++++++++++
>>  1 file changed, 724 insertions(+)
>
> [...]
>
>> +* Guix System with Full Disk Encryption::    Guix System with Full Disk 
>> Encryption
>
> AFAIU the steps, especially the partitioning that does not provide an
> UEFI dedicated partition, are specific to Libreboot systems: what about
> to make it more clear in the section title?

I will mention this somewhere.  Thanks.  Perhaps we could mention that
libreboot systems are so ancient that they do not support UEFI.  I will
also mention that newer coreboot devices do not support a UEFI partition,
but require proprietary blobs to run properly.

>
> ...or to adapt the section by separating Libreboot specific instructions
> from generic system instructions?

as above.

>
> [...]
>
>> +Create a physical volume in the partition.
>> +
>> +@example
>> +pvcreate /dev/mapper/partname --verbose
>> +@end example
>> +
>> +Create a volume group in the physical volume, where @code{vgname} is any
>> +desired name for volume group.
>> +
>> +@example
>> +vgcreate vgname /dev/mapper/partname --verbose
>> +@end example
>> +
>> +Create logical volumes in the volume group; where "num" is the number
>> +for space in GB, and @code{lvnameroot} and @code{lvnamehome} are any
>> +desired names for root and home volumes respectively.
>> +
>> +@example
>> +lvcreate --extents 25%VG vgname --name lvnameroot --verbose
>> +lvcreate --extents 100%FREE vgname --name lvnamehome --verbose
>> +@end example
>> +
>> +Create filesystems on the logical-volumes, where @code{fsnameroot} and
>> +@code{fsnamehome} are any desired names for root and home filesystems
>> +respectively.
>> +
>> +@example
>> +mkfs.btrfs --metadata dup --label fsnameroot /dev/vgname/lvnameroot
>> +mkfs.btrfs --metadata dup --label fsnamehome /dev/vgname/lvnamehome
>> +@end example
>
> Why using two BTRFS volumes on top of LVM and not directly using BTRFS
> (with subvolumes if you want) on top of /dev/mapper/partname?

This is probably a good idea...however does the grub payload support
this?

>
> AFAIU the "double mapping" it's not needed, BTRFS have a very good (and
> now mature) built in volume manager.  Furthermore, using BTRFS for
> volume management will allow users to switch to a multi-device system
> (e.g. RAID1) very easily.

That's pretty cool!

>
> I'm still using LVM on some "legacy" systems but for new installations
> I'd strogly suggest starting using BTRFS on top of "physical"
> partitions.

does btrfs volume manage allow use to use ext4, jfs, or xfs filesystems?
Or does on LVM do that?

>> +Mount the filesystems under the current system.
>> +
>> +@example
>> +mount --label fsnameroot --target /mnt --types btrfs --verbose
>> +mkdir --verbose /mnt/home && mount --label fsnamehome --target \
>> +/mnt/home --types btrfs --verbose
>> +@end example
>> +
>> +Create a swap file.
>> +
>> +@example
>> +dd bs=1MiB count=1GiB if=/dev/zero of=/mnt/swapfile status=progress
>> +mkswap --verbose /mnt/swapfile
>> +@end example
>
> I know that since Linux 2.6 swapfile performance is not a big issue if
> the file is unfragmented (and it'll be for sure on newly partitioned
> filesystems) but AFAIU swap files are still a little bit problematic on
> BTRFS
> https://btrfs.wiki.kernel.org/index.php/FAQ#Does_Btrfs_support_swap_files.3F:

Ok...maybe we could use ext4 for the swap file?  Is there a better
filesystem?  Again does btrfs volume management allow the swap file to
be ext4?  Or do we have to use LVM?

> From kernel 5.0+ btrfs have native swap files support, but with some
> limitations. Swap file - must be fully allocated as NOCOW with no
> compression on one device.
>
>
> I've never tested a system with swap file on BTRFS but I think that your
> instructions should add how to set NOCOW for the swap file.
>
> The above example could be:
>
>
> @example
> dd bs=1MiB count=1GiB if=/dev/zero of=/mnt/swapfile status=progress
> mkswap --verbose /mnt/swapfile
> chattr +C /mnt/swapfile
> btrfs property set /mnt/swapfile compression none
> @end example
>
> Final note: AFAIU BTRFS supports swap files ONLY in single device
> settings (that is: NO swap file support on multi device settings), so
> IMHO it's better to use a dedicated partition for the swap space so
> users are free to switch to a multi-device setting if they wish (and
> can).

Ok, I will create a dedicated partition and format it with ext4 and the
swap program...but I will probably need help figuring out how to encrypt
the swap partition...There are guides online that I can look at...

> The problem with a fully encrypted dedicated swap partition is that
> it'll require a third passphrase prompt on boot (the one to unlock the
> swap partition), but that's a minor annoyance IMHO.

Oh no!  I hadn't thought about that!  grrr!  I wonder if bcachefs is
better than btrfs...well I guess it's not merged yet.  What about
instead of using a swap file we use zram?  Or how about both?

> What do you think?
>
> [...]
>
> Happy hacking! Gio'

--
Joshua Branson (jab in #guix)
Sent from Emacs and Gnus
  https://gnucode.me
  https://video.hardlimit.com/accounts/joshua_branson/video-channels
  https://propernaming.org
  "You can have whatever you want, as long as you help
enough other people get what they want." - Zig Ziglar