我设置了一个包含 Windows11 和 Linux 的多操作系统系统。我发现可以挂载位锁 加密的 ntfs来自 Linux 的 Windows 分区（/dev/sda3 作为 root）：
cryptsetup bitlkDump /dev/sda3
cryptsetup open -y --readonly --type=bitlk /dev/sda3 bitlk-65536
mount -t ntfs -o,ro /dev/mapper/bitlk-65536 /mnt/
# ...
umount /dev/mapper/bitlk-65536
cryptsetup close bitlk-65536
我一直用只读 旗帜对彼此而言密码设置 打开和山 选项对于映射器。这是可能的山 位锁 加密的 ntfs分割读写， 喜欢：
/dev/mapper/bitlk-65536 /mnt 类型 ntfs3 (rw,nosuid,nodev,relatime,uid=1000,gid=1000,iocharset=utf8,windows_names,uhelper=udisks2)
对已安装的写入（删除）操作有多大风险位锁 ntfs3分割？根据文档，添加它甚至已经是有风险和实验性的位锁视窗ntfs分区到 /etc/crypttab 并在 Linux 启动时解密并挂载 Windows 分区。
我想问一下，在我必须再次设置 Windows11 之前（在可能的文件系统崩溃之后）。
亲切的问候，
答案1
简短回答：
它是安全的，但请确保始终进行备份（无论涉及何种存储技术，您都应该对不想丢失的所有数据进行备份）。
长答案：
BitLocker 是一项专有技术，磁盘元数据的规范不公开。
这意味着 Linux 中对 BitLocker 的所有支持都是由于逆向工程所以 Linux 中总是有可能出现一些错误的地方。好消息是，这个问题主要存在于读取和解析磁盘元数据时，而不是实际读取和写入数据时，这只是标准 AES-XTS（带有旧版本 BitLocker 的 AES-CBC）加密，它是默认情况下，LUKS 也使用它，因此实际处理从磁盘读取数据和向磁盘写入数据的内核代码经过了充分测试且安全。
此外，BitLocker 上的 NTFS 只是标准 NTFS，因此一旦cryptsetup解析元数据并解锁 BitLocker 设备并且您获得了可以安装的 NTFS 文件系统，就不会出现太多可能导致数据丢失的错误。 （或者至少没有什么比在没有 BitLocker 的情况下写入普通 NTFS 更危险的了）。
解析 BitLocker 元数据并解密卷加密密钥是一个挑战，即使cryptsetup出现错误，您也无法挂载 NTFS 文件系统（并通过向其写入内容来损坏它），因为明文设备将仅包含垃圾（无法安装的错误解密数据，即使这种情况不应该发生，cryptsetup 中的 BitLocker 支持的编写方式使得元数据中任何未知或意外的内容都将导致早期错误）。
cryptsetup 中的 BitLocker 支持仍标记为实验性，但已添加到2.3.0，大约 4 年前，所以自从它被很多人测试以来，我不知道有人丢失数据（到目前为止）。所以使用起来可能相当安全。
答案2
由于加密的性质，如果解密正确，写入加密卷可能并不比写入未加密卷更危险。现代加密不允许解密部分失败，它故意是全有或全无操作。
话虽如此，从 Linux 挂载甚至未加密的 NTFS 卷也是极其危险的，尤其是如果系统有可能在不卸载它的情况下重新启动的话。即使没有加密，如果卸载出现任何问题，即使正常重新启动，卷也可能被损坏，这也存在很高的风险。 （我什至看到 Windows 在这些情况下损坏了自己的卷，但这种情况不太常见。）
此外，将加密密钥存储在文件中会带来安全风险。通常，bitlocker 将密钥存储在 TPM 中，因此将其存储在文件中根本违背了使用 bitlocker 的目的。加密 Linux 卷并将其密钥存储在 TPM 中可能会在一定程度上缓解这种情况，但是这种削弱的安全态势以及在两个操作系统之间共享 NTFS 的风险使人们对共享这样的加密卷的明智性产生了怀疑。