如何扩展LUKS2

Question

几年前，我读过一篇关于LUKS1如何在没有数据丢失的情况下向右和相邻的自由空间扩展的指南，但无法向左扩展。现在LUKS2已经具备了许多新的特性，它在左边扩展时是否有不同的地方而没有数据丢失？

Answer 1

这是不可能的--现在。元数据格式建议它应该是可行的，但到目前为止，它还没有实际实现。因此，您应该坚持旧的“重新定位所有数据”，或者“创建新的分区，让LVM担心它”。对于LUKS1和大多数文件系统，您也是这样做的。

LUKS2 2报头有一个数据段的概念：

对象包含磁盘上包含用户数据(在LUKS1中称为用户数据有效负载)的加密区域的定义。对于普通的LUKS设备，只有一个数据段存在。在数据再加密过程中，根据新密钥和旧密钥对数据区域进行内部划分，但只需向用户提供一个抽象区域。

对于数据段，应该可以将LUKS头移动到左侧，继续指向原始数据(第一段)，并使用空闲空间(在标头和数据段之间)作为一个新的数据段，逻辑上附加到加密设备的末尾。就像LVM将任意一组物理范围附加到逻辑卷中一样。

但这只是个理论。

到目前为止，还没有实现此功能的实际使用/工具，我也不知道是否有计划这样做。

我试着用非常规的方法(概念的证明，某种程度上)：

# truncate -s 100M foobar.img
# cryptsetup luksFormat --type=luks2 foobar.img
# cryptsetup luksOpen foobar.img foobar
# yes > /dev/mapper/foobar
# sync
# hexdump -C /dev/mapper/foobar
00000000  79 0a 79 0a 79 0a 79 0a  79 0a 79 0a 79 0a 79 0a  |y.y.y.y.y.y.y.y.|
*
05400000

LUKS2加密了是模式。数据段是什么样的？

# cryptsetup luksDump foobar.img
Data segments:
  0: crypt
    offset: 16777216 [bytes]
    length: (whole device)
    cipher: aes-xts-plain64
    sector: 512 [bytes]
# strings -n 100 foobar.img
"segments":{"0":{"type":"crypt","offset":"16777216","iv_tweak":"0","size":"dynamic","encryption":"aes-xts-plain64","sector_size":512}}

后者实际上是原始的LUKS2元数据--它是JSON格式。我们稍后再编辑..。

让我们把它种到左边(增加100米)：

# truncate -s 100M barfoo.img
# cat foobar.img >> barfoo.img
# ls -lh *.img
-rw-r--r-- 1 root root 200M Jun  9 20:57 barfoo.img
-rw-r--r-- 1 root root 100M Jun  9 20:53 foobar.img

因此，barfoo.img是100米的新空位，其次是100米原来的LUKS集装箱。

将LUKS报头重新定位到设备的新启动：

# dd bs=1M count=16 if=foobar.img of=barfoo.img conv=notrunc
# cryptsetup luksOpen barfoo.img barfoo
# hexdump -C -n 16 /dev/mapper/barfoo
00000000  4e a6 39 e7 e0 e8 63 ae  81 72 29 81 5f 1b 08 c2  |N.9...c..r)._...|
00000010

现在可以打开它，但是数据段仍然指向旧的偏移量(16 this )，但是当然，它并不在那里--我们增加了1亿，所以这个数据段的偏移量现在应该是116 this。

编辑它(偏移16777216到偏移121634816)：

# strings -n 100 barfoo.img | head -n 1 > barfoo.json
# nano -w barfoo.json
# dd if=barfoo.json of=barfoo.img bs=1 seek=4096 conv=notrunc
# dd if=barfoo.json of=barfoo.img bs=1 seek=20480 conv=notrunc

结果：

# cryptsetup luksDump barfoo.img
Device barfoo.img is not a valid LUKS device.

哦，但是当然。LUKS2现在也有元数据校验和。它不想让你用nano编辑东西，用dd破坏标题。对你来说没有神秘的魔法，先生。好吧，直到你把校验和也补上.

# cryptsetup luksDump barfoo.img --debug
# LUKS2 header version 2 of size 16384 bytes, checksum sha256.
# Checksum:8552bf514ab70b53e63180e9fdd3bb59db1385e3dca87f792f8197b33b851aa1 (on-disk)
# Checksum:e6f322921feae0193bcbc4cddc23b87b7f192266b4a2ef34847580fd7ca18a3e (in-memory)
# LUKS2 header checksum error (offset 0).

...basically将磁盘上的校验和替换为内存中的校验和。

# echo e6f322921feae0193bcbc4cddc23b87b7f192266b4a2ef34847580fd7ca18a3e |
  xxd -r -ps - |
  dd of=barfoo.img bs=1 seek=448 conv=notrunc

结果(现在真的)：

# cryptsetup luksDump barfoo.img
Data segments:
  0: crypt
    offset: 121634816 [bytes]
    length: (whole device)
    cipher: aes-xts-plain64
    sector: 512 [bytes]
# hexdump -C /dev/mapper/barfoo
00000000  79 0a 79 0a 79 0a 79 0a  79 0a 79 0a 79 0a 79 0a  |y.y.y.y.y.y.y.y.|
*
05400000

在这一点上，我们已经成功地移动了卢克斯的头100米左。但设备大小还是一样的..。现在，我们可以添加另一个数据段了吗？有一个免费的100米部分，从偏移16M到116米。让我们将它添加到JSON中。

# nano -w barfoo.json
man this is unreadable
# jq < barfoo.json > barfoo.pretty
# nano -w barfoo.pretty
...
  "segments": {
    "0": {
      "type": "crypt",
      "offset": "121634816",
      "iv_tweak": "0",
      "size": "88080384",
      "encryption": "aes-xts-plain64",
      "sector_size": 512
    },
    "1": {
      "type": "crypt",
      "offset": "16777216",
      "iv_tweak": "172032",
      "size": "104857600",
      "encryption": "aes-xts-plain64",
      "sector_size": 512
    }
  },
  "digests": {
    "0": {
      "type": "pbkdf2",
      "keyslots": [
        "0"
      ],
      "segments": [
        "0",
        "1"
      ],
...and so on and so forth...

结果：

# cryptsetup luksDump barfoo.img
Data segments:
  0: crypt
    offset: 121634816 [bytes]
    length: 88080384 [bytes]
    cipher: aes-xts-plain64
    sector: 512 [bytes]

  1: crypt
    offset: 16777216 [bytes]
    length: 104857600 [bytes]
    cipher: aes-xts-plain65
    sector: 512 [bytes]

不幸的是，在这一点上，设备打开良好，有正确的尺寸增加(YAY!)，但数据是错误的(NOO!)。逻辑字节0被映射到物理字节16 the，而不是预期的116 the。

嘿，那是1段，不是0段，你这个傻比利！哪里出了问题？

我不知道。这就好像你不应该做简单的元数据修改来解锁还没有人测试过的隐藏特性。

也许这是由于我缺乏理解，但即使把片段放在相反的方向，它仍然会继续以错误的顺序打开它们。有什么东西是按照物理偏移来分类的吗？但是为什么呢？

所以不幸的是，这个特别的魔法以失败告终。要么是因为我做错了什么，要么就是它还没有准备好使用。尽管如此，它的功能还是不错的，所以对未来仍有希望。

请注意，即使它确实有效，也不建议您使用它。