根据网上很多教程，将TPM存储的密钥添加到LUKS的过程是运行clevis luks bind -d /dev/sda1 tpm2 '{"pcr_ids": "7"}'，但我收到以下错误：
ERROR: pcr-input-file filesize does not match pcr set-list
ERROR: Could not build pcr policy
ERROR: Unable to run tpm2_createpolicy
Invalid input!
所以我删除了 pcr_ids 并且命令变为clevis luks bind -d /dev/sda1 tpm2 '{}'. 这很好用。将“密码短语”添加到插槽并将磁盘添加到 /etc/crypttab（使用 tpm2-device=auto）使磁盘能够在启动时自动解密。
我不确定它是否足够安全。这种做法有任何漏洞吗？
PS 我在 MSI X570A-PRO 上使用 AMD 5950X（及其 ftpm）
我已经用 LUKS 加密了我笔记本电脑上的操作系统和交换分区。当我启动时，如果我输入错误的密码，它会在第一次尝试时停止。这看起来很奇怪，但对我来说没关系。问题是它会立即进入 grub 救援模式，而我在手册中看到的大多数 grub 命令都不起作用。我假设在救援模式下没有加载额外的模块。我只是想重新启动我的电脑，但无法识别halt、normal或类似命令。唯一的方法是使用硬件按钮关闭。有没有更好的重启方式？
操作系统是 OpenSUSE 15.2
GRUB2 2.04
所以我有几个问题。
1) 使用 LUKS 加密支持 SED 的驱动器对驱动器没有积极影响吗？我的猜测是它会提供双层加密作为积极因素，但我不确定，这就是我在这里的原因。
2）如果有正面影响，这些与可能的负面影响如何权衡？对我来说，这似乎是减慢驱动器的速度，但我又不确定。
3) 如果没有/几乎没有正面影响，我应该购买支持 SED 的驱动器还是使用 LUKS 加密驱动器？
我正在尝试创建一个大小为 10M 的加密卷。我知道这是可能的，因为我有 10M 大小的坟墓。我已经运行了以下命令。
fallocate -l 10M container
cryptsetup -y -v luksFormat --progress-frequency 1 container
cryptsetup open --type luks container luksvol1
我收到以下错误消息。
Requested offset is beyond real size of device container.
但是如果我的容器大小为 20M，我的命令就会成功。为什么这会在 10M 时失败？10M 应该足够大以容纳加密的 luks 卷。
在从外部 LUKS raid 10 阵列（通过 e-sata 连接）到内部驱动器的 rsync 期间，操作系统冻结。
重新启动后，我无法再访问外部 RAID 10。当我单击它时，我收到以下错误消息：
Error mounting filesystem
Error mounting /dev/dm-0 at /media/marco/EXT_RAID_10: can't read superblock
on /dev/mapper/luks-49aa238c-96bc-4bf6-abeb-1f4b018ccabe (udisks-error-quark, 0)
该系统是带有 Budgie 桌面的 Ubuntu 服务器 18.04.3。所有 4 个驱动灯都亮起，表明它们应该没问题
sudo fdisk -l 的输出：
Disk /dev/nvme0n1: 465.8 GiB, 500107862016 bytes, 976773168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk /dev/sda: 223.6 GiB, 240057409536 bytes, 468862128 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x373d828f
Device Boot Start End Sectors Size Id Type
/dev/sda2 2048 468860927 468858880 223.6G 5 Extended
/dev/sda5 443695104 468860927 25165824 12G 82 Linux swap / Solaris
/dev/sda6 4096 226996223 226992128 108.2G 83 Linux
/dev/sda7 226998272 443693055 216694784 103.3G 83 Linux
Partition table entries are not in disk order.
Disk /dev/sdf: 3.7 TiB, 4000694927360 bytes, 7813857280 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: B9829E9E-44BE-4381-BB42-387062B5252D
Device Start End Sectors Size Type
/dev/sdf1 2048 7813855231 7813853184 3.7T unknown
Disk /dev/mapper/luks-49aa238c-96bc-4bf6-abeb-1f4b018ccabe: 3.7 TiB, 4000690733056 bytes, 7813849088 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
sudo fsck.ext4 -v /dev/sdf1 的输出：
e2fsck 1.44.1 (24-Mar-2018)
ext2fs_open2: Bad magic number in super-block
fsck.ext4: Superblock invalid, trying backup blocks...
fsck.ext4: Bad magic number in super-block while trying to open /dev/sdf1
The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem. If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
or
e2fsck -b 32768 <device>
/dev/sdf1 contains a crypto_LUKS filesystem
sudo mke2fs -n /dev/sdf1 的输出：
Creating filesystem with 976731648 4k blocks and 244187136 inodes
Filesystem UUID: 11a09e27-4114-4555-8dd3-afcf61deacc4
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
102400000, 214990848, 512000000, 550731776, 644972544
sudo e2fsck -b 98304 /dev/sdf1 的输出：
e2fsck 1.44.1 (24-Mar-2018)
e2fsck: Bad magic number in super-block while trying to open /dev/sdf1
The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem. If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
or
e2fsck -b 32768 <device>
/dev/sdf1 contains a crypto_LUKS filesystem
最后，问题只是驱动器由于中断的 rsync 命令而被锁定（当我中断一个简单的 cp 命令时也发生了）。LUKS 加密使这个简单的锁定变得复杂，给出了神秘的（双关语）错误消息。我通过按照以下说明移除锁解决了这个问题： https ://alvinabad.wordpress.com/2012/09/22/how-to-recover-a-luks-encrypted-disk/
简而言之：
1. Boot from a recovery disk
2. Determine /dev address of locked LUKS partition (in this case /dev/sdh1):
~$ sudo fdisk -l
3. Display LUKS header info:
~$ sudo cryptsetup -v luksDump /dev/sdh1
4. Unlock partition with LUKS passphrase:
~$ sudo cryptsetup -v luksOpen /dev/sdh1 sdh1_crypt
5. Mount drive using Nautilus or manually:
~$ mkdir /tmp/disk
~$ sudo mount /dev/mapper/sdh1_crypt /tmp/disk
我注意到有时vgchange -a n [vgname]似乎没有正确关闭卷组。这种情况最常发生，当我实际准备一个新系统时，我不知道是什么原因造成的。考虑以下磁盘结构（的输出lsblk -o name,fstype）
NAME FSTYPE
/dev/sdx
+- /dev/sdx1 crypto_LUKS
| +- test_luks LVM2_member
| | +- test_lvm-test ext4
当我以正常方式（，等）打开所有这些东西时cryptsetup open ...，vgchange -a y ...做一些事情test_lvm-test，然后用
umount [mountpoint of test_lvm-test]
vgchange -a n test_lvm
cryptsetup close test_luks
test_lvmvgs按预期从输出中消失。但是，如果我刚刚创建了这个结构（见下文重现），第一次安装它，然后以同样的方式关闭它，test_lvm不会从vgs. 相反，vgs抱怨物理卷的设备“没有被过滤器找到或拒绝”。要从vgs我必须重新打开test_luks和删除错误test_lvm，请再次禁用test_lvm并再次关闭test_luks。
为什么会这样？为什么LVM在第一次挂载时保留了test_lvmafter的句柄，但之后没有？vgchange -a n test_lvm; cryptsetup close test_luks
我能够像这样在 VirtualBox 中使用 Arch Linux Live CD“Arch Linux 5.2.5-arch1-1-ARCH”最一致地重现这种行为
# Let /dev/sdx1 be the partition to test this on
#
# Create LVM on LUKS with one ext4 volume
#
cryptsetup luksFormat --cipher aes-xts-plain64 --hash sha256 --label "Test (Encrypted)" /dev/sdx1
cryptsetup open /dev/sdx1 test_luks
pvcreate /dev/mapper/test_luks
vgcreate test_lvm /dev/mapper/test_luks
lvcreate --extents 100%FREE test_lvm --name test
mkfs.ext4 -L Test /dev/test_lvm/test
#
# Mount volume and write to it
#
mount /dev/test_lvm/test /mnt
echo "Hello World" > /mnt/test.txt
#
# Unmount everything
#
umount /mnt
vgchange -a n test_lvm
# -> 0 logical volume(s) in volume group "test_lvm" now active
cryptsetup close test_luks
#
# Check vgs
#
vgs
# -> Warning: Device for PV [uuid] not found or rejected by a filter.
# -> Warning: Device for PV [same uuid] not found or rejected by a filter.
# -> Couldn't find device with uuid [same uuid again].
# -> VG #PV #LV #SM Attr VSize VFree
# -> test_lvm 1 1 0 wz-pn- 492.00m 0
#
# Mount and unmount again
#
cryptsetup open /dev/sdx1 test_luks
vgs
# No error this time
vgchange -a n test_lvm
cryptsetup close test_luks
# test_lvm no longer listed in vgs and no errors.
我正在使用cryptsetup 2.1.0，默认加密选项是（如 所报告cryptsetup --help）：
Default compiled-in device cipher parameters:
LUKS: aes-xts-plain64, Key: 256 bits, LUKS header hashing: sha256, RNG: /dev/urandom
LUKS: Default keysize with XTS mode (two internal keys) will be doubled.
我也在阅读LUKS 状态的ArchLinux dm-crypt wiki ：
默认情况下使用 256 位密钥大小。但是请注意，XTS 将提供的密钥分成两半，因此要使用 AES-256 而不是 AES-128，您必须将 XTS 密钥大小设置为 512。
我对密钥大小加倍/减半感到困惑。我不明白是否：
--key-size 256在命令行上发出，并且程序将其加倍为 512，以有效地获得 AES-256。这就是联机帮助页似乎所说的“将加倍”--key-size 512在命令行上发出，并且程序将其减半，有效地执行 AES-256。ArchLinux 页面似乎就是这么说的。(1) 或 (2) 是哪一个？换句话说，我需要知道在命令行上明确给出的密钥大小等同于默认值（256 或 512？），以及产生的有效 AES 强度（AES-128 或 AES-512 ？）。