linux-kernel - Re: [PATCH 09/14] target/configfs: Expose protection device attributes

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: <1389642191.12062.32.camel@dabdike.int.hansenpartnership.com>
Date:	Mon, 13 Jan 2014 11:43:11 -0800
From:	James Bottomley <James.Bottomley@...senPartnership.com>
To:	"Nicholas A. Bellinger" <nab@...ux-iscsi.org>
Cc:	"Martin K. Petersen" <martin.petersen@...cle.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>,
	Sagi Grimberg <sagig@...lanox.com>,
	Or Gerlitz <ogerlitz@...lanox.com>
Subject: Re: [PATCH 09/14] target/configfs: Expose protection device
 attributes

On Mon, 2014-01-13 at 11:27 -0800, Nicholas A. Bellinger wrote:
> On Mon, 2014-01-13 at 10:52 -0800, James Bottomley wrote:
> > On Mon, 2014-01-13 at 10:30 -0800, Nicholas A. Bellinger wrote:
> > > Hey MKP,
> > > 
> > > On Fri, 2014-01-10 at 16:01 -0500, Martin K. Petersen wrote:
> > > > >>>>> "nab" == Nicholas A Bellinger <nab@...erainc.com> writes:
> > > > 
> > > > nab> This patch adds support for exposing DIF protection device
> > > > nab> attributes via configfs.  This includes:
> > > > 
> > > > nab>    pi_prot_type: Protection Type (0, 1, 3 currently support)
> > > > nab>    pi_prot_version: Protection Version (DIF v1 currently supported)
> > > > 
> > > > What's DIF v2?
> > > > 
> > > 
> > > This would be the proposed 16-byte protection scheme for SBC4.
> > 
> > What proposed 16 byte scheme?  The only DIF proposals I know for SBC-4
> > are 13-185R0 and 12-369R0 and that's a couple of new algorithms and
> > types because we cannot change the 8 byte PI.
> > 
> 
> Then I'm probably getting the SBC version wrong..  It's the one that
> includes using CRC32C for the block guard, and larger space for
> reference tag as mentioned by MKP.

Well, this isn't reducing my confusion:  I think you're referring to
12-369r0 which proposes to *eliminate* the reference tag (by moving it
into the CRC calculation) and use the recovered 4 bytes to expand the
CRC to CRC32 and add two bytes to the application tag, so they both
become 4 bytes long, but the new PI still occupies only 8 bytes on disk.

Perhaps it's also better to clarify the terminology:  The PI is composed
of a Guard field, which is the checksum, an application tag, which is
usable by the application for anything it wants and a reference tag
which is designed to be derived from the on-disk location so it can be
used to detect misplaced writes.  In Type 1 the reference tag has to be
the lower 31 bits of the LBA and in type 3 it's application defined.  In
all current types, the guard is two bytes and the application tag two
bytes.

James


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