linux-kernel - Re: [PATCH 07/14] target/sbc: Add P_TYPE + PROT_EN bits to READ_CAPACITY

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]

Date:	Fri, 10 Jan 2014 11:50:50 -0800
From:	Andy Grover <agrover@...hat.com>
To:	"Nicholas A. Bellinger" <nab@...ux-iscsi.org>
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>,
	"Martin K. Petersen" <martin.petersen@...cle.com>,
	Christoph Hellwig <hch@....de>, Hannes Reinecke <hare@...e.de>,
	Or Gerlitz <ogerlitz@...lanox.com>
Subject: Re: [PATCH 07/14] target/sbc: Add P_TYPE + PROT_EN bits to READ_CAPACITY_16

On 01/09/2014 10:21 PM, Nicholas A. Bellinger wrote:
>> What about FORMAT_UNIT emulation?
>
> Would certainly be useful to have..
>
>> The backstore protection configuration is done at the target side via
>> configfs/targetcli, if you publish DIF support in
>> INQUERY_EVPD/READ_CAPACITY you need to accept protection information format?
>
> Mmmm, these two bits bits are following what scsi_debug is currently
> exposing minus FORMAT_UNIT support..?
>
> MKP..?

Yes, don't you need FORMAT UNIT because protection information is going 
to mean the pi-enabled lun will need to report less blocks? The ramdisk 
backstore changes in this series allocate extra space for PI info, but 
my understanding was that especially for emulation with block and fileio 
backstores, everything needs to go in the same amount of space.

Furthermore, if we want PI info stored along with the blocks, then block 
and fileio backstore formats are no longer going to be 1:1 -- requiring 
offset calculations, non-aligned read-modify-write, and all that 
unpleasantness to be handled?

I've looked at the patchset and the code looks good to me, so I guess 
I'm trying to understand the scope of future work needed on the 
backstore side for this support to be functional.

Regards -- Andy

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