linux-kernel - Re: [PATCH v4 00/19] ublk: add support for integrity data

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aWUI-4Z30PlhDB_Z@fedora>
Date: Mon, 12 Jan 2026 22:45:15 +0800
From: Ming Lei <ming.lei@...hat.com>
To: Caleb Sander Mateos <csander@...estorage.com>
Cc: Jens Axboe <axboe@...nel.dk>, Shuah Khan <shuah@...nel.org>,
	linux-block@...r.kernel.org, linux-kselftest@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Stanley Zhang <stazhang@...estorage.com>,
	Uday Shankar <ushankar@...estorage.com>,
	"Martin K . Petersen" <martin.petersen@...cle.com>
Subject: Re: [PATCH v4 00/19] ublk: add support for integrity data

On Thu, Jan 08, 2026 at 02:19:28AM -0700, Caleb Sander Mateos wrote:
> Much work has recently gone into supporting block device integrity data
> (sometimes called "metadata") in Linux. Many NVMe devices these days
> support metadata transfers and/or automatic protection information
> generation and verification. However, ublk devices can't yet advertise
> integrity data capabilities. This patch series wires up support for
> integrity data in ublk. The ublk feature is referred to as "integrity"
> rather than "metadata" to match the block layer's name for it and to
> avoid confusion with the existing and unrelated UBLK_IO_F_META.
> 
> To advertise support for integrity data, a ublk server fills out the
> struct ublk_params's integrity field and sets UBLK_PARAM_TYPE_INTEGRITY.
> The struct ublk_param_integrity flags and csum_type fields use the
> existing LBMD_PI_* constants from the linux/fs.h UAPI header. The ublk
> driver fills out a corresponding struct blk_integrity.
> 
> When a request with integrity data is issued to the ublk device, the
> ublk driver sets UBLK_IO_F_INTEGRITY in struct ublksrv_io_desc's
> op_flags field. This is necessary for a ublk server for which
> bi_offload_capable() returns true to distinguish requests with integrity
> data from those without.
> 
> Integrity data transfers can currently only be performed via the ublk
> user copy mechanism. The overhead of zero-copy buffer registration makes
> it less appealing for the small transfers typical of integrity data.
> Additionally, neither io_uring NVMe passthru nor IORING_RW_ATTR_FLAG_PI
> currently allow an io_uring registered buffer for the integrity data.
> The ki_pos field of the struct kiocb passed to the user copy
> ->{read,write}_iter() callback gains a bit UBLKSRV_IO_INTEGRITY_FLAG for
> a ublk server to indicate whether to access the request's data or
> integrity data.
> 
> Not yet supported is an analogue for the IO_INTEGRITY_CHK_*/BIP_CHECK_*
> flags to ask the ublk server to verify the guard, reftag, and/or apptag
> of a request's protection information. The user copy mechanism currently
> forbids a ublk server from reading the data/integrity buffer of a
> read-direction request. We could potentially relax this restriction for
> integrity data on reads. Alternatively, the ublk driver could verify the
> requested fields as part of the user copy operation.
> 
> v4:
> - Add max_integrity_segments to struct ublk_param_integrity (Ming)
> - Move UBLKSRV_IO_INTEGRITY_FLAG to avoid overflow from
>   QID + UBLKSRV_IO_BUF_OFFSET (Ming)
> - Check UBLK_F_INTEGRITY when UBLKSRV_IO_INTEGRITY_FLAG is used (Ming)
> - Initialize integrity backing file to disable integrity checks (Ming)
 
Hi Jens,

Can you consider to queue V4 into for-7.0/block if you are fine? So I can rebase
my BATCH_IO patchset against this one.

Thanks,
Ming