all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Giovanni Biscuolo <g@xelera.eu>
To: Joshua Branson <jbranso@dismail.de>
Cc: 49654@debbugs.gnu.org, rg@raghavgururajan.name
Subject: [bug#49654] [PATCH] doc: Add full disc encryption guide to the cookbook
Date: Wed, 21 Jul 2021 14:16:13 +0200	[thread overview]
Message-ID: <87k0ljj20i.fsf@xelera.eu> (raw)
In-Reply-To: <87eebsvokg.fsf@dismail.de>

[-- Attachment #1: Type: text/plain, Size: 5614 bytes --]

Hi Joshua

Joshua Branson <jbranso@dismail.de> writes:

[...]

>> 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?

Do you mean: does grub support booting from encrypted BTRFS?  The answer
is yes.

WARNING: I've (still) not tried myself to boot Guix System using an
encrypted BTRFS (sub)volume but I'm pretty confident that Guix is
configuring grub with the needed modules (luks and btrfs)

[...]

>> 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?

No: BTRFS is a volume manager and a filesystem "all in one", you cannot
create a BRTFS subvolume and format it with another filesystem

> Or does on LVM do that?

LVM is "just" a volume manager with no idea about the overlaying
filesystem


[...]

>> 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?

No, al explained above

> Or do we have to use LVM?

If we use a dedicated partition for swap there is no need to set up an
LVM volume (phisical, VG and then logical): we can just create a
dedicate partition during partitioning, encrypt it with LUKS and
"mkswap" it (e.g. mkswap /dev/mapper/<encrypted_swap>)

[...]

>> 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

There's no need to format (mkfs.ext4) the partition with ext4, just
"mkswap" it :-)

> ...but I will probably need help figuring out how to encrypt
> the swap partition...There are guides online that I can look at...

You have to encrypt it like any other partition, e.g.:

--8<---------------cut here---------------start------------->8---

Encrypt swap the partition. Follow the prompts.

@example
cryptsetup --verbose --hash whirlpool --cipher serpent-xts-plain64 \
--verify-passphrase --use-random --key-size 512 --iter-time 500 \
luksFormat /dev/<swap_partition>
@end example

Obtain and note down the UUID of the LUKS partition.

@example
cryptsetup --verbose luksUUID /dev/<swap_partition>
@end example

Open the encrypted partition, where @code{luks-uuid} is the LUKS UUID,
and @code{crypt_swap01} is any desired name for the decrypted swap
partition.

@example
cryptsetup --verbose luksOpen UUID=luks-uuid crypt_swap01
@end example

Format the encrypted swap

@example
mkswap /dev/mapper/crypt_swap01
@end example

--8<---------------cut here---------------end--------------->8---

Then, in our (operating-system) declaration, we have to use something
like this:
--8<---------------cut here---------------start------------->8---

  (mapped-devices
   (list
    (mapped-device
     (source (uuid "LUKS-UUID"))
     (target "partname")
     (type luks-device-mapping))
    ;; This is our new encrypted swap partition
    (mapped-device
     (source
      (uuid "SWAP-LUKS-UUID"))
     (target "crypt_swap01")
     (type luks-device-mapping))
    (mapped-device
     (source "vgname")
     (targets
      (list
       "vgname-lvnameroot"
       "vgname-lvnamehome"))
     (type lvm-device-mapping))))

  (swap-devices
   (list
    "/dev/mapper/crypt_swap01"))

--8<---------------cut here---------------end--------------->8---

WARNING: please consider I've not tested this code.

>> 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!

Actually what I said it's NOT true... or better: we could avoid the
(third) password prompt for the swap partition if we _add_ a keyfile to
the LUKS encrypted swap partition _and_ we have a mechanism to
"luksOpen" that mapped volume using that keyfile.

I'm not aware of such a mechanism on Guix Systems, in Debian (et al)
this is done with /etc/crypttab, AFAIU the luks-device-mapping lacks the
option to specify a keyfile.

So, as far as this cookbook section is concerned, unfortunately when
using a dedicated encrypted swap partition an additional passphrase
prompt will be presented to the user at each boot.

> I wonder if bcachefs is better than btrfs...well I guess it's not
> merged yet.

No, still not.  AFAIU also still not available in Guix.

> What about instead of using a swap file we use zram?

Never used zram and I don't know if it's supported (I mean configured by
(operating-system)) on Guix System

[...]

Sorry I've more issues than answers on this topics, nevertheless I hope
it somway helps.

Thanks! Gio'

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 849 bytes --]

  reply	other threads:[~2021-07-21 12:17 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-20  5:22 [bug#49654] [PATCH] doc: Add full disc encryption guide to the cookbook Joshua Branson via Guix-patches via
2021-07-20 10:41 ` Giovanni Biscuolo
2021-07-20 18:15   ` Joshua Branson via Guix-patches via
2021-07-21 12:16     ` Giovanni Biscuolo [this message]
2021-07-21 22:50 ` Sarah Morgensen
2021-07-22 19:16 ` jbranso--- via Guix-patches via
2021-08-11 14:17   ` Ludovic Courtès
2021-08-12  1:48   ` jbranso--- via Guix-patches via
2021-08-12  8:04     ` Ludovic Courtès
2021-08-12  8:59       ` david larsson
2021-08-12  8:41     ` jbranso--- via Guix-patches via

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87k0ljj20i.fsf@xelera.eu \
    --to=g@xelera.eu \
    --cc=49654@debbugs.gnu.org \
    --cc=jbranso@dismail.de \
    --cc=rg@raghavgururajan.name \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.