| Message ID | 20191231034701.GA10716@lappy |
|---|---|
| State | Under Review |
| Headers | show |
| Series | [bug#38826] doc: Mention no LUKS2 for luks-device-mapping | expand |
Hi, On Mon, 30 Dec 2019 21:47:01 -0600 David Trudgian <dave@trudgian.net> wrote: > I spent a bit of time trying to mount some existing LUKS2 devices on > boot in a Guix system. They worked to open and mount manually in a > booted system, but not on boot with luks-device-mapping. Eventually > worked out LUKS2 is not supported by the code that inspects the > superblock directly for the (LUKS1) UUID. > > A mention LUKS2 is not supported in the docs might be nice. I agree. But better yet would be to implement LUKS2 in the uuid code. Since you have such a device could you find where the magic number / uuid parts in it are? Both references [1] and [2] say that the magic number is 6 bytes and the uuid is at offset 168 Byte, length 40 Byte. Endianness is also big endian in both, so I have no idea where the problem comes from. The code should work for both. [1] LUKS1 on-disk format: https://gitlab.com/cryptsetup/cryptsetup/-/wikis/LUKS-standard/on-disk-format.pdf [2] LUKS2 on-disk format: https://habd.as/post/external-backup-drive-encryption/assets/luks2_doc_wip.pdf
Danny, David, Danny Milosavljevic 写道： > David Trudgian <dave@trudgian.net> wrote: >> A mention LUKS2 is not supported in the docs might be nice. > > I agree. Same. Would you consider submitting a patch, David? Or writing the text? > But better yet would be to implement LUKS2 in the uuid code. Has LUKS2 support[0] been added to GRUB yet? Last I checked it hadn't. Which isn't to say that we shouldn't get our own house in order, of course. Kind regards, T G-R [0]: https://lists.gnu.org/archive/html/grub-devel/2019-11/msg00000.html
Guix, Good news: Eli Schwartz (在 Savannah)： > Follow-up Comment #5, bug #55093 (project grub): > > Yay, this is implemented in > https://git.savannah.gnu.org/cgit/grub.git/commit/?id=365e0cc3e7e44151c14dd29514c2f870b49f9755 I'll take a look later. We'll see whether or not it would be prudent to ship this as-is in Guix. Kind regards, T G-R
>> Yay, this is implemented in >> https://git.savannah.gnu.org/cgit/grub.git/commit/?id=365e0cc3e7e44151c14dd29514c2f870b49f9755 > > I'll take a look later. We'll see whether or not it would be prudent > to ship this as-is in Guix. I had a look at this before, and the issue remaining is that the LUKS2 support in GRUB via this patch is not compatible with the default PBKDF that is going to be used by cryptsetup when creating LUKS2 partitions. Looking at `cryptsetup --help` on Guix or elsewhere will show that the default LUKS2 PBKDF is argon2i. Unfortunately only pbkdf2 is supported by this GRUB2 patch (it's the default PBKDF for LUKS1). It's possible to create LUKS2 encrypted partitions using pbkdf2, but this means they aren't using a PBKDF of the same strength that most people expect from LUKS2 use elsewhere - in distros where an unencrypted `/boot` is used to avoid the direct support in GRUB problem. I'm not sure if this is a major concern or not here? Have spent some of my morning writing up about encryption in Singularity containers, which uses LUKS2... so this is a fun topic to see in my mailbox right now :-) Cheers, DT
diff --git a/doc/guix.texi b/doc/guix.texi index 70e3dfea6a..232d99d508 100644 --- a/doc/guix.texi +++ b/doc/guix.texi @@ -69,6 +69,7 @@ Copyright @copyright{} 2019 Jakob L. Kreuze@* Copyright @copyright{} 2019 Kyle Andrews@* Copyright @copyright{} 2019 Alex Griffin@* Copyright @copyright{} 2019 Guillaume Le Vaillant@* +Copyright @copyright{} 2019 David C. Trudgian@* Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or @@ -11470,6 +11471,10 @@ This must be a @code{mapped-device-kind} object, which specifies how This defines LUKS block device encryption using the @command{cryptsetup} command from the package with the same name. It relies on the @code{dm-crypt} Linux kernel module. + +Note that currently only LUKS1 encrypted devices are supported. Existing +LUKS2 devices can be opened and mounted after boot, using +@code{cryptsetup luksOpen}. @end defvr @defvr {Scheme Variable} raid-device-mapping
I spent a bit of time trying to mount some existing LUKS2 devices on boot in a Guix system. They worked to open and mount manually in a booted system, but not on boot with luks-device-mapping. Eventually worked out LUKS2 is not supported by the code that inspects the superblock directly for the (LUKS1) UUID. A mention LUKS2 is not supported in the docs might be nice. Cheers, Dave Trudgian From 97ed4c1859e797adf4ba813ac7db3d1b8261a569 Mon Sep 17 00:00:00 2001 From: David Trudgian <EMAIL> Date: Mon, 30 Dec 2019 21:37:35 -0600 Subject: [PATCH] Mention no LUKS2 in luks-device-mapping doc --- doc/guix.texi | 5 +++++ 1 file changed, 5 insertions(+)