linux-kernel - Re: [PATCH 00/14] target: Initial support for DIF Type1+Type3 emulation

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 for Android: free password hash cracker in your pocket

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

Date:	Wed, 15 Jan 2014 13:55:20 -0800
From:	"Nicholas A. Bellinger" <nab@...ux-iscsi.org>
To:	sagi grimberg <sagig@...lanox.com>
Cc:	"Nicholas A. Bellinger" <nab@...erainc.com>,
	target-devel <target-devel@...r.kernel.org>,
	linux-scsi <linux-scsi@...r.kernel.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	"Martin K. Petersen" <martin.petersen@...cle.com>,
	Christoph Hellwig <hch@....de>, Hannes Reinecke <hare@...e.de>,
	Or Gerlitz <ogerlitz@...lanox.com>
Subject: Re: [PATCH 00/14] target: Initial support for DIF Type1+Type3
 emulation

On Wed, 2014-01-15 at 20:03 +0200, sagi grimberg wrote:
> On 1/8/2014 10:36 PM, Nicholas A. Bellinger wrote:
> > From: Nicholas Bellinger <nab@...ux-iscsi.org>
> >
> > Hi MKP & SCSI folks,
> >
> > This series contains initial support for target mode DIF Type1+Type3
> > emulation within target core, RAMDISK_MCP device backend, and tcm_loop
> > fabric driver.
> >
> > DIF emulation is enabled via a new 'pi_prot_type' device attribute
> > within configfs, which is set after initial device configuration and
> > before target fabric LUN export occurs.
> >
> > The DIF read/write verify emulation has been made generic enough so
> > it can be used by other backend drivers (eg: FILEIO), as well as
> > DIF v2 in the near future.  Also note that the majority of the logic
> > has been groked from existing scsi_debug.c code.
> >
> > The current plan is to enable basic support for emulated backends with
> > tcm_loop for v3.14 code, and then move onto IBLOCK backend support
> > (that requires BLOCK layer changes)
> 
> Hey Nic,
> Can you please elaborate on what BLOCK layer changes are required?
> I didn't spot any misses from Looking at 
> Documentation/block/data-integrity.txt.
> 
> Am I missing something?

The issue is that existing fs/bio-integrity.c code always assumes
client/initiator mode, in that it will attempt to
bio_integrity_generate() protection information in the submit_bio WRITE
path, and bio_integrity_verify() of protection information in the
bio_endio READ completion path.

So we'll need a server/target passthrough mode where existing protection
information can be attached during bio setup in IBLOCK code, and the
response be propagated back up without the extra verify, including
propagating up potential Guard + Reference tag failures to the original
submit_bio() caller.

--nab

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/