cryptsetup issueshttps://gitlab.com/cryptsetup/cryptsetup/-/issues2019-06-27T12:40:23Zhttps://gitlab.com/cryptsetup/cryptsetup/-/issues/368cryptsetup cannot resize by size instead of blocks2019-06-27T12:40:23ZMaciej Piechotkacryptsetup cannot resize by size instead of blocksCurrently to resize luks you need to specify number of sectors. This is different than virtually any other tool (partitioning, LVM, resize2fs...). It is very easy to make a mistake during such operation and it is potentially destructive ...Currently to resize luks you need to specify number of sectors. This is different than virtually any other tool (partitioning, LVM, resize2fs...). It is very easy to make a mistake during such operation and it is potentially destructive so avoiding the unnecessary hand calculation is probably good.v2.2.0Ondrej KozinaOndrej Kozinahttps://gitlab.com/cryptsetup/cryptsetup/-/issues/395Make cryptsetup-reencrypt resistant to unexpected hardware failure2019-08-15T20:31:11ZDennis YangMake cryptsetup-reencrypt resistant to unexpected hardware failureHi,
For the past couple of days, I have been working on cryptsetup-reencrypt source code and hoping to find a way to make cryptsetup-reencrypt resistant to unexpected failure. I think the reason reencrypt might lose data after failure i...Hi,
For the past couple of days, I have been working on cryptsetup-reencrypt source code and hoping to find a way to make cryptsetup-reencrypt resistant to unexpected failure. I think the reason reencrypt might lose data after failure is that the reencrypt/encrypt/decrypt process could read and overwrite the same data range between write log commits. This makes me wonder if we can always have a spare space (no smaller than reencrypt block size) to decouple the read and overwrite block between log commits with "--use-fsync" which commits log after overwriting every block.
For example, if we try to add LUKS encryption to not yet encrypted device, we could use this command after we shrinks the filesystem for at least 4096 sectors.
`cryptsetup-reencrypt /dev/sdb1 --new -B 2 --reduce-device-size 4096S --use-fsync`
In this case, since data have been shifted for 4096 sectors (2MBytes) and block size is limited to 2MB, we should not have any data loss even if we force reboot during the process.
I am aware of that you guys has already been working on an online re-encryption tools which solves this issue, but I still want to know if I am missing anything about how to make this offline tool resistant to unexpected failure.v2.2.0Ondrej KozinaOndrej Kozinahttps://gitlab.com/cryptsetup/cryptsetup/-/issues/387Cryptsetup reencrypt resilience2019-08-15T20:31:55ZCMajeric.majeri@gmail.comCryptsetup reencrypt resilienceHello,
From what I see in the code, even with fsync and write-log, reencrypt will lose 1 block of data on hardware failures.
Is that correct?
If so, are there any plans for a `--reliable` or similar flag which will perform writes more ...Hello,
From what I see in the code, even with fsync and write-log, reencrypt will lose 1 block of data on hardware failures.
Is that correct?
If so, are there any plans for a `--reliable` or similar flag which will perform writes more atomically? This could be achieved very simply by maintaining a write ahead log file or two.
Thanks.v2.2.0Ondrej KozinaOndrej Kozinahttps://gitlab.com/cryptsetup/cryptsetup/-/issues/446LUKS2 RFE: provide optional switch to serialize usage of memory hard function...2021-11-29T14:04:07ZOndrej KozinaLUKS2 RFE: provide optional switch to serialize usage of memory hard functions in a systemDuring system boot involving many LUKS2 devices (with Argon2 enabled keyslots), there's risk of overall boot failure with hard to debug OOM events:
Example case: system has 2GB of memory in total, we have 3 or more LUKS2 devices created...During system boot involving many LUKS2 devices (with Argon2 enabled keyslots), there's risk of overall boot failure with hard to debug OOM events:
Example case: system has 2GB of memory in total, we have 3 or more LUKS2 devices created with default pbkdf keyslot parameters (Argon2 for LUKS2 format). Each LUKS2 devices requires ~1GB of memory to unlock a keyslot successfully. If cryptsetup open (or systemd-cryptsetup equivalent) commands are run sequentially there's low risk for oom event to happen. If we invoke all unlock commands in parallel one or more (or all of them) can get terminated by oom killer.
This is hard to debug especially in situation where we fail to mount rootfs due to it and we have (under such memory pressure) no spare space for system logs (syslog or journald gets killed often in the process as well) to store it.
We'll provide optional activation flag enabling all processes (using libcryptsetup) to serialize usage of memory hard functions in the system. The serialization point shall be lock placed in cryptsetup locking directory.
cryptsetup CLI will ignore the flag unless requested explicitly by the user.v2.2.0Ondrej KozinaOndrej Kozina