On 9/9/25 2:23 PM, Ingo Franzki wrote:
On 09.09.2025 14:15, Milan Broz wrote:
On 9/9/25 1:50 PM, Ingo Franzki wrote:
On 09.09.2025 13:47, Milan Broz wrote:
On 9/9/25 1:18 PM, Ingo Franzki wrote:
Please, revert my patches and run the same test on a clean 6.17.0-rc5 just
to verify that the
On 9/9/25 1:18 PM, Ingo Franzki wrote:
Please, revert my patches and run the same test on a clean 6.17.0-rc5 just
to verify that the patches do not introduce the bug.
With your patches reverted the combined mode fails the same way as with your
patches.
So they did not introduce the bug.
Plea
On 9/9/25 3:51 PM, Harald Freudenberger wrote:
On 2025-09-09 14:15, Milan Broz wrote:
On 9/9/25 1:50 PM, Ingo Franzki wrote:
On 09.09.2025 13:47, Milan Broz wrote:
On 9/9/25 1:18 PM, Ingo Franzki wrote:
Please, revert my patches and run the same test on a clean
6.17.0-rc5 just
to verify that
On 9/9/25 1:50 PM, Ingo Franzki wrote:
On 09.09.2025 13:47, Milan Broz wrote:
On 9/9/25 1:18 PM, Ingo Franzki wrote:
Please, revert my patches and run the same test on a clean 6.17.0-rc5 just
to verify that the patches do not introduce the bug.
With your patches reverted the combined mode
On 7/10/25 6:10 PM, Eric Biggers wrote:
On Thu, Jul 10, 2025 at 10:28:55AM +0200, Milan Broz wrote:
On 7/9/25 9:09 PM, Eric Biggers wrote:
The support for asynchronous hashes in dm-verity has outlived its
usefulness. It adds significant code complexity and opportunity for
bugs. I don&#
On 7/10/25 5:55 PM, Bart Van Assche wrote:
On 7/10/25 1:28 AM, Milan Broz wrote:
Just one nitpick - could you please increase minor version of dm-
verity target, so we have information in debug log that it is a
patched version?
Others are convinced that version numbers have no place in the
On 7/9/25 9:09 PM, Eric Biggers wrote:
The support for asynchronous hashes in dm-verity has outlived its
usefulness. It adds significant code complexity and opportunity for
bugs. I don't know of anyone using it in practice. (The original
submitter of the code possibly was, but that was 8 years
On 7/4/25 8:28 PM, Robin H. Johnson wrote:
If an entire device is formatted as LUKS, there is a small chance it
maybe be detected as an Atari/AHDI disk - causing the kernel to create
partitions, and confusing other systems.
Detect the LUKS header before the Atari partition table to prevent this
On 6/23/25 8:22 PM, Eric Biggers wrote:
Of course, the correct solution is to just add MD5 support to lib/crypto/ and
use that here. All that's needed is a single MD5 context (88 bytes), and direct
calls to the MD5 code...
Feel free to port dm-crypt to this code once MD5 is in lib ;-)
(Use of
overflow.
How about this patch?
For v2:
Tested-by: Milan Broz
Just for the context, the patch fixes OOPS on 32bit (but 64bit should overflow
struct too):
: Oops: Oops: [#1] SMP
: CPU: 1 UID: 0 PID: 12 Comm: kworker/u16:0 Not tainted 6.16.0-rc2+ #993
PREEMPT(full)
: Hardware name: VM
-by: Milan Broz
Signed-off-by: Herbert Xu
Yes, that fixes the issue, thanks!
Tested-by: Milan Broz
Mikulas, I think this should go through DM tree, could you send it for 6.16?
The full patch is here
https://lore.kernel.org/linux-crypto/afte3kdzxcazc...@gondor.apana.org.au/T/#u
diff --git a/dri
Hi,
On 2/25/25 4:38 PM, Christoph Hellwig wrote:
...
Then we have new (undocumented) value for NVMe in
- /sys/block//integrity/metadata_bytes
This contains the correct 64.
Yes, this contains the full size of the metadata. And besides
documenting it we should probably also lift it to the
On 2/25/25 11:10 AM, Kanchan Joshi wrote:
On 2/25/2025 2:53 PM, Milan Broz wrote:
Hi,
I tried to add some support for using devices with PI/DIF metadata
and checked (through sysfs) how large metadata space per sector
is available.
The problem is that some values behave differently than I
Hi,
I tried to add some support for using devices with PI/DIF metadata
and checked (through sysfs) how large metadata space per sector
is available.
The problem is that some values behave differently than I expected.
For an NVMe drive, reformatted to 4096 + 64 profile, I see this:
- /sys/block
]
...
Signed-off-by: Milan Broz
Fixes: fb0987682c62 ("dm-integrity: introduce the Inline mode")
Cc: sta...@vger.kernel.org # 6.11+
---
drivers/md/dm-integrity.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/md/dm-integrity.c b/drivers/md/dm-integri
: Milan Broz
---
drivers/md/dm-integrity.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/md/dm-integrity.c b/drivers/md/dm-integrity.c
index 555dc06b9422..c45464b6576a 100644
--- a/drivers/md/dm-integrity.c
+++ b/drivers/md/dm-integrity.c
On 2/10/25 1:54 PM, Mikulas Patocka wrote:
...
Can you send me the output of:
# sg_vpd -p bl /dev/sdN
and maybe hdparm -I too? I'd like to see if we can come up with a
reasonable heuristic.
--
Martin K. Petersen Oracle Linux Engineering
I don't have that USB-SATA bridge that reports o
On 2/10/25 4:04 PM, Mikulas Patocka wrote:
Do forward error correction if metadata I/O fails.
Signed-off-by: Mikulas Patocka
Not directly related to this patch, but...
please could you also increase the dm-verity version?
I just implemented support for the errors-as-corruption
dm-verity flag
This patch adds documentation for new 'I' mode for dm-integrity
introduced in commit
fb0987682c62 ("dm-integrity: introduce the Inline mode").
Signed-off-by: Milan Broz
---
Documentation/admin-guide/device-mapper/dm-integrity.rst | 5 +
1 file changed, 5 inserti
This patch adds documentation for new option introduced in commit
4441686b24a1 ("dm-crypt: Allow to specify the integrity key size as option").
Signed-off-by: Milan Broz
---
Documentation/admin-guide/device-mapper/dm-crypt.rst | 5 +
1 file changed, 5 insertions(+)
di
This patch adds documentation for options introduced in commit
f811b83879fb ("dm-verity: introduce the options restart_on_error and
panic_on_error").
Signed-off-by: Milan Broz
---
Documentation/admin-guide/device-mapper/verity.rst | 9 +
1 file changed, 9 insertions(+)
di
like to keep this for the ability to access legacy images,
but it should not be used by anything else.
I tested the patch below with the images we have in the cryptsetup
testsuite, and it works ok.
So if you want, add
Tested-and-reviewed-by: Milan Broz
Milan
Signed-off-by: Eric Biggers
On 1/20/25 4:16 PM, Mikulas Patocka wrote:
Some SATA SSDs and most NVMe SSDs report physical block size 512 bytes,
but they use 4K remapping table internally and they do slow
read-modify-write cycle for requests that are not aligned on 4K boundary.
Therefore, io_opt should be aligned on 4K.
Thi
On 1/6/25 2:43 AM, Yu Kuai wrote:
On 1/3/25 5:25 PM, Mikulas Patocka wrote:
Milan, what do you think about this from a cryptographic point of view?
Does it make sense to add an option that would detect zero data and skip
decryption in this case?
It is a very dangerous thing.
Disk encryption i
On 1/3/25 5:25 PM, Mikulas Patocka wrote:
Milan, what do you think about this from a cryptographic point of view?
Does it make sense to add an option that would detect zero data and skip
decryption in this case?
It is a very dangerous thing.
Disk encryption is a length-preserving encryption,
On 12/26/24 8:43 PM, Eric Biggers wrote:
From: Eric Biggers
Remove the vmac64 template, as it has no known users. It also continues
to have longstanding bugs such as alignment violations (see
https://lore.kernel.org/r/20241226134847.6690-1-evepolon...@gmail.com/).
...
No in-tree user has a
Caching RS parity bytes is already done in fec_decode_bufs() now,
no need to use yet another buffer for conversion to uint16_t.
This patch removes that double copy of RS parity bytes.
Signed-off-by: Milan Broz
---
drivers/md/dm-verity-fec.c | 31 ++-
1 file changed
is corrupted
...
With this fix, errors are properly repaired.
: verity-fec: 7:1: FEC 0: corrected 4 errors
Signed-off-by: Milan Broz
Fixes: 8ca7cab82bda ("dm verity fec: fix misaligned RS roots IO")
Cc: sta...@vger.kernel.org
---
drivers/md/dm-verity-fec.c | 40
On 10/17/24 10:28 PM, Eric Biggers wrote:
On Thu, Oct 17, 2024 at 10:17:04PM +0200, Milan Broz wrote:
On 10/17/24 9:44 PM, Eric Biggers wrote:
On Wed, Oct 16, 2024 at 04:27:48PM -0700, Eric Biggers wrote:
Add a new device-mapper target "dm-inlinecrypt" that is similar to
dm-crypt bu
On 10/17/24 9:44 PM, Eric Biggers wrote:
On Wed, Oct 16, 2024 at 04:27:48PM -0700, Eric Biggers wrote:
Add a new device-mapper target "dm-inlinecrypt" that is similar to
dm-crypt but uses the blk-crypto API instead of the regular crypto API.
This allows it to take advantage of inline encryption
On 10/7/24 7:45 AM, Christoph Hellwig wrote:
On Fri, Oct 04, 2024 at 09:21:47PM +0200, Milan Broz wrote:
There was another discussion recently. I also discussed this with Mikulas
as DM maintainer, and we agreed this is the best way.
Extending dm-crypt is possible, but the dm-crypt threat
-256-XTS is the
only supported cipher.
Maybe I'm stepping into a mine-field here, but if this simply uses
blk-crypto to accellerate a subset of dm-crypt, why isn't dm-crypt
simply enhanced to use blk-crypto when available?
compatible,
Milan Broz (cryptsetup maintainer) has said that
On 10/1/24 11:11 AM, Mikulas Patocka wrote:
...
If I add that 'reboot-on-eio' flag, should it also restart the kernel with
kernel_restart("dm-verity device corrupted")? Or, should it use a
different string?
If we are already here revisiting it, maybe think if there are more errors that
should
On 9/25/24 11:28 PM, Luca Boccassi wrote:
Do people use veritysetup (libcryptsetup) here, or does it run with its
separate userspace tooling?
This is used with libcryptsetup commonly, and often with veritysetup.
It is fairly easy to test in a VM or on baremetal, it is not required
to build yo
On 9/24/24 11:59 PM, Eric Biggers wrote:
On Wed, Sep 25, 2024 at 12:36:01AM +0300, Jarkko Sakkinen wrote:
On Tue Sep 24, 2024 at 9:27 PM EEST, Mikulas Patocka wrote:
On Tue, 24 Sep 2024, Jarkko Sakkinen wrote:
On Mon Sep 23, 2024 at 5:04 PM EEST, Mikulas Patocka wrote:
On Sun, 22 Sep 202
On 9/25/24 8:09 AM, Maxim Suhanov wrote:
Hello.
This is a very strange reasoning. I can say that restarting on an IO error
(that can happen in normal situations) could cause another security issue,
such as DoS. EIO is not a data integrity error; it can happen even higher
in the storage stack...
On 9/24/24 8:36 PM, Mikulas Patocka wrote:
On Tue, 24 Sep 2024, Akilesh Kailash wrote:
On Tue, Sep 24, 2024 at 10:44 AM Sami Tolvanen wrote:
Hi Mikulas,
On Tue, Sep 24, 2024 at 6:18 AM Mikulas Patocka wrote:
Maxim Suhanov reported that dm-verity doesn't crash if an I/O error
happens. In
On 7/30/24 1:58 PM, Md Sadre Alam wrote:
Set cc->iv_size to 4 bytes instead of 8 bytes, since
this cc->iv_size is passing as data unit bytes to
blk_crypto_init_key(). Since CQHCI driver having
limitation for data unit bytes to 32-bit only.
In dm-crypt, plain64 IV is defined as "little-endian 64
On 7/19/24 6:23 AM, Shin'ichiro Kawasaki wrote:
The test case dm/002 rarely fails with the message below:
dm/002 => nvme0n1 (dm-dust general functionality test) [failed]
runtime 0.204s ... 0.174s
--- tests/dm/002.out2024-06-14 14:37:40.480794693 +0900
+++ /home/sh
ubmitted it upstream - and then nobody
apparently fixed it.)
So, I am quite happy this hack can go away!
I run full cryptsetup testuite with this patch and everything
works, nice cleanup.
Reviewed-by: Milan Broz
Thanks,
Milan
Tested by:
$ dd if=/dev/urandom of=key.bin bs=512 count=1
$ cryp
On 5/28/24 12:12 AM, Eric Wheeler wrote:
On Wed, 15 May 2024, Mikulas Patocka wrote:
Hi
Some NVMe devices may be formatted with extra 64 bytes of metadata per
sector.
Here I'm submitting for review dm-crypt patches that make it possible to
use per-sector metadata for authenticated encryption.
On 4/14/24 3:05 AM, Eric Wheeler wrote:
Hello all,
I'm not sure if this is a bug or a feature, so thought I'd report it.
These are all for Linux 6.6.26:
If you start with a 512-byte backing device (logical and physical):
# blockdev --getss --getpbsz /dev/nvme9n9
512
512
Hi,
this lo
On 4/8/24 9:36 PM, Mikulas Patocka wrote:
It was reported that dm-crypt performs badly when the system is loaded[1].
So I'm adding an option "high_priority" that sets the workqueues and the
write_thread to nice level -20. This used to be default in the past, but
it caused audio skipping, so it ha
On 2/26/24 7:47 AM, Weiß, Simone wrote:
...
I can do it this way for sure as well. Another point still in my mind is the
superblock: I would like to get rid of the build time switch and carry
information about lazy commits enabled in the superblock. As there is J, B, D
and R as mode already, a ne
Hi,
there is a kernel crash during when running our cryptsetup testsuite
if using veritysetup with --use-tasklets option (try_verify_in_tasklet table
option).
With
# veritysetup format /dev/sdb /dev/sdc
# veritysetup open /dev/sdb test /dev/sdc --use-tasklets
it generates BUG below, bisect
45 matches
Mail list logo
