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
Task Type Bug Report
Category Kernel
Status Closed
Assigned To No-one
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

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 :)
Comment by Erich Eckner (deepthought) - Monday, 25 November 2019, 20:02 GMT
The issue persist with linux-5.3.13.1-1

Loading...