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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <1389839550.5567.643.camel@haakon3.risingtidesystems.com>
Date:	Wed, 15 Jan 2014 18:32:30 -0800
From:	"Nicholas A. Bellinger" <nab@...ux-iscsi.org>
To:	"Martin K. Petersen" <martin.petersen@...cle.com>
Cc:	sagi grimberg <sagig@...lanox.com>,
	"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>,
	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:42 -0500, Martin K. Petersen wrote:
> >>>>> "nab" == Nicholas A Bellinger <nab@...ux-iscsi.org> writes:
> 
> nab> The issue is that existing fs/bio-integrity.c code always assumes
> nab> client/initiator mode, in that it will attempt to
> nab> bio_integrity_generate() protection information in the submit_bio
> nab> WRITE path, and bio_integrity_verify() of protection information in
> nab> the bio_endio READ completion path.
> 
> Only if the submit_bio() caller hasn't attached protection information
> already. If you submit a bio with a bip already attached the block layer
> will not generate/verify.
> 

Mmm, missed that detail.  So that would take care of the passthrough for
the WRITE case then..

How about a passthrough on the READ completion side for target fabrics
doing a hardware VERIFY..?  Any preferences how this should work..?

Also, for IBLOCK responses to properly generate GUARD + REFERENCE tag
CHECK_CONDITION sense failures from an underlying device VERIFY failure,
there will also need to be a way to propagate up the failure status
through bio_endio().  I assume bio_integrity_payload is the proper place
for adding something like this..?

One other item from my TODO list for IBLOCK protection support is how to
go about determining which DIF type to expose in the target, based upon
what is currently enabled on the underlying struct block_device.  I'm
currently trying to deduce the protection type by looking at struct
blk_integrity, but it would be helpful to make this explicit with
bi->prot_type.

--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/