FS#64626 - device-mapper integrity: read:verify is being ignored
Attached to Project:
Arch Linux
Opened by Erich Eckner (deepthought) - Saturday, 23 November 2019, 21:35 GMT
Last edited by freswa (frederik) - Friday, 21 February 2020, 21:25 GMT
Opened by Erich Eckner (deepthought) - Saturday, 23 November 2019, 21:35 GMT
Last edited by freswa (frederik) - Friday, 21 February 2020, 21:25 GMT
|
Details
Description:
I have an unclean integrity device, but setting /sys/block/dm-0/integrity/read_verify to 0 (it was 1 before) still produces read errors - as I understand the manual, it should however not check integrity upon read if set to 0. Additional info: * package version(s) linux 5.3.12.1-1 cryptsetup 2.2.2-1 * config and/or log files etc. reads lead to the follwing errors in dmesg: [202293.687796] device-mapper: crypt: dm-1: INTEGRITY AEAD ERROR, sector 0 [202293.687897] device-mapper: crypt: dm-1: INTEGRITY AEAD ERROR, sector 0 [202293.687903] Buffer I/O error on dev dm-1, logical block 0, async page read * link to upstream bug report, if any https://www.redhat.com/archives/dm-devel/2019-November/msg00114.html Steps to reproduce (as root): > dd if=/dev/zero of=raw bs=1M count=1024 > losetup loop0 raw > echo key > key > cryptsetup luksFormat /dev/loop0 --integrity hmac-sha256 --integrity-no-wipe --key-file $(pwd)/key > cryptsetup luksOpen /dev/loop0 test --key-file key > base64 < /dev/mapper/test | uniq base64: read error: Input/output error # this is expected! > echo 0 > /sys/block/$(readlink -e /dev/mapper/test_dif | cut -d/ -f3)/integrity/read_verify > base64 < /dev/mapper/test | uniq base64: read error: Input/output error # this is not expected! |
This task depends upon
Closed by freswa (frederik)
Friday, 21 February 2020, 21:25 GMT
Reason for closing: None
Additional comments about closing: This seems pretty stalled to me. If it's still an issue. Please fill a re-open request. Thank you :)
Friday, 21 February 2020, 21:25 GMT
Reason for closing: None
Additional comments about closing: This seems pretty stalled to me. If it's still an issue. Please fill a re-open request. Thank you :)
Comment by
Erich Eckner (deepthought) -
Monday, 25 November 2019, 20:02 GMT
The issue persist with linux-5.3.13.1-1