doc: Mention no LUKS2 for luks-device-mapping

  • Open
  • quality assurance status badge
Details
3 participants
  • Danny Milosavljevic
  • David Trudgian
  • Tobias Geerinckx-Rice
Owner
unassigned
Submitted by
David Trudgian
Severity
normal
D
D
David Trudgian wrote on 31 Dec 2019 04:47
(address . guix-patches@gnu.org)
20191231034701.GA10716@lappy
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(+)

Toggle diff (25 lines)
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
--
2.24.1
D
D
Danny Milosavljevic wrote on 2 Jan 2020 23:32
(name . David Trudgian)(address . dave@trudgian.net)(address . 38826@debbugs.gnu.org)
20200102233256.4250ec30@scratchpost.org
Hi,

On Mon, 30 Dec 2019 21:47:01 -0600
David Trudgian <dave@trudgian.net> wrote:

Toggle quote (8 lines)
> 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.

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl4Ob5gACgkQ5xo1VCww
uqWH7wf/b5jd4jE/f3DndnK1iydrT7RksluS/PPqh4u/LxGt2cOg18TTuRLnFV0V
tMFDK+noiJz5Q9RqHOYORtpLIInS820FH6auP0TyhpeqPGHa/I7qXmrA6MM27FOw
bHrAB12xYtTlFgiLZYVJLKLtL1mjmoGuF3l6O/+eRd+0yaeGf36u2wccj8li3T5a
1zqClutAYxSlTphZw4l0bd5XYDGnZr+GF/sa13x1ZLvex6xc8D1ApNNV2uFfYcft
iVr+ar0c6t4pusmLZJY8X6tsKf+JS51lHw7yu7idqj13laU14nF51Q0YKZrfSc2G
YZhFClydKV+2jiPxHarWPKDoIM+7FA==
=lAXg
-----END PGP SIGNATURE-----


T
T
Tobias Geerinckx-Rice wrote on 2 Jan 2020 23:53
(address . 38826@debbugs.gnu.org)
87png18o7d.fsf@nckx
Danny, David,

Danny Milosavljevic ???
Toggle quote (5 lines)
> 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?

Toggle quote (2 lines)
> 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]:
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEfo+u0AlEeO9y5k0W2Imw8BjFSTwFAl4OdHYACgkQ2Imw8BjF
STzekhAAjdt/4xrlKT84zJq1JOGkGXBJcOMtUoPcSOJ6ICLk30W6VLn4+YnaxBJu
qL4s338BnKLTJWIxXRzpuXe+G0ZOltRz6DD8QH2tGl9H7wAWpq6PyIMasmjnsA3h
lNl7E/ABXE421pSo53bv5olqppFkYRvnRLp4B/Y9BvHpgqyZU6kXsXBhgdhms8eB
kZNsWc8XLaO9IVhXHyG9GwnmANemKRMwbhSU/UgtY0mYFjw62jB+7OPvK5Dz/BVK
p8o+Pm8NS/aRbjPFmSkL/6N+cpIoeh2PhH+xw4uSBkAfSqY16iLjxSXriASYtJPF
prjLxZIF9O/TyIKNO9x7vOnTjP0D8vs0nkgVJnf9J7/ONugOGMtvGL5p1lbuo0EH
i4wFl4N8bBy4N0YlPvv7OYkQeX1p3LPOlvriN0VZMQk5O269f6SMZm58AU6dlzDt
nXD8+qFuQsja6gCIHd5trjCNR+fB24sJx0zi2Q65eTJp/dgiLQL4RMFnfyfYU3O2
WDCeuiAjkrqynSbhA2llMd0VTX7KkxjCSyhf0BGIBXMd/piD9s5WW5tqpnooeF4T
LPqcRK5S0+c+pUFW4+SDVrCxBtHfjQtWstM/5acKeBuNNLW+I2AvxsDrbgL4Tq/V
zKptNX9pxX3TqjetTsjeyCytJ6L8wLNqWQJGzsNJWI023F3aksI=
=l89/
-----END PGP SIGNATURE-----

D
D
David Trudgian wrote on 3 Jan 2020 02:56
(name . Tobias Geerinckx-Rice)(address . me@tobias.gr)
8736cxl2um.fsf@lappy.randomroad.net
Hi Danny, Tobias,

Toggle quote (7 lines)
>>> 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?

My original email had a patch attached (or should have). Apologies -
there was no [PATCH] on the subject. Attaching here in case.

Toggle quote (2 lines)
>> But better yet would be to implement LUKS2 in the uuid code.

I intend to take a look at this when I get time in the next week or so.

Toggle quote (3 lines)
> Has LUKS2 support[0] been added to GRUB yet? Last I checked it
> hadn't.

I don't believe GRUB has LUKS2 support for booting from an encrypted
partition merged yet. The last I saw there was a patch for LUKS2 but it
didn't support the Argon 2i PBKDF which is the default you get when you
use LUKS2 in distros where a separate `/boot` is kept unencrypted, so it
wouldn't be useful yet.

It would still be good to be able to boot from LUKS1 but mount non-boot
LUKS2 partitions, so people like me coming from other distros can mount
their encrypted `/home` or similar without having to convert to LUKS1.

I have actually converted to LUKS1, which requires converting the key to
pbkdf2 first...

cryptsetup luksConvertKey --pbkdf=pbkdf2 /dev/sdc1
cryptsetup convert /dev/sdc1 --type luks1

...but I can easily create LUKS2 things to work on the UUID code.

Cheers,

DT
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(+)

Toggle diff (25 lines)
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
--
2.24.1
T
T
Tobias Geerinckx-Rice wrote on 10 Jan 2020 16:39
Fwd: [bug #55093] Add LUKS2 support
(address . 38826@debbugs.gnu.org)
87imljcodn.fsf@nckx
Guix,

Good news:

Eli Schwartz (? Savannah)?
Toggle quote (5 lines)
> 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
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEfo+u0AlEeO9y5k0W2Imw8BjFSTwFAl4YmpQACgkQ2Imw8BjF
STz8kg//V9k2P6Kb0WKNe9wLd1tnkounnTL238bBDkhUtwbSXIosr2j3x2n1/9g0
MCXCJHOnPxxgG2nremMNdKMkQUTCsFnTxEb7X+yrlOrnkXa+qHhSBtlCzbMAvT08
qrfu9bCe4dZetgcCQNJ+mLQT1Ad61SSYRWtNyn6HlNOQit+NsZV5b6vC9m9NIvrU
vC6TKP2IfV2EIHAOssHRemTMJLwpSIL/UBvV8p8ru70ROSp1vJOX7ffjy7tiYBUt
FkJFcwLBegpuOIxDLE28YX7MLAHmCZ70PhhE2ru3snUSENW/38romiP2djiIgmQW
1rXXbeeDRb5qs6DHkqtoHqAmjsnNA6/2/l/0S6Q3+O920oCrbcYCPmC1Yj+MPX1r
8gUqdtXphbTS0VUeTlwykdoyfL1Bf2VG6tpYskEUepFajN2wXlwBLJWog7sRu0Tx
kvLnQec/VJEzmjwBAW/VB64FdqWydL+I8Bq4zTNfujzSD6jDpevW7iwYK0dMxsgf
PhYY+IpVEN3G1Lex1qv4bmB8f8n5qFhR18/4PW2ibYMHfCUD5cZWb0SjB+eV537w
OX9wVMbADo4oi377MyFwWVWvyB2bfP+PR+udsp+wER7kEkU25TFRCi0uaqL3ZnoV
h7DZKfXRdK9UgWDhFh72My1m7ASHhB6DnbDOzY19CThAF9kr9zs=
=eSEO
-----END PGP SIGNATURE-----

D
D
David Trudgian wrote on 10 Jan 2020 20:03
(name . Tobias Geerinckx-Rice)(address . me@tobias.gr)(name . 38826)(address . 38826@debbugs.gnu.org)
16f90d6f00f.e61facad831696.4328929059229895663@trudgian.net
Toggle quote (7 lines)
>> 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
Attachment: file
?