linux-kernel - Re: status of block-integrity

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:	Wed, 08 Jan 2014 08:14:35 +0100
From:	Hannes Reinecke <hare@...e.de>
To:	"Martin K. Petersen" <martin.petersen@...cle.com>
CC:	"Darrick J. Wong" <darrick.wong@...cle.com>,
	chuck.lever@...cle.com, Christoph Hellwig <hch@...radead.org>,
	Jens Axboe <axboe@...nel.dk>, linux-kernel@...r.kernel.org,
	linux-scsi@...r.kernel.org
Subject: Re: status of block-integrity

On 01/07/2014 10:43 PM, Martin K. Petersen wrote:
>>>>>> "Hannes" == Hannes Reinecke <hare@...e.de> writes:
> 
> Hannes> Plus (as hch rightly pointed out) as there is no defined
> Hannes> userland interface the question is why we bother with all the
> Hannes> DIX stuff in the block layer.  
> 
> Because it catches problems in the path between block layer and HBA
> ASIC? FWIW, we find more issues there than we do between initiator and
> target.
> 
But how should it do that exactly?
As there is no user (apart from oracleasm) no-one can attach
protection information to any data, so even the most dedicated admin
cannot exercise this path, let alone find issues here.

> API issues aside, another reason adoption has been slow is that very few
> applications truly care about this stuff. The current approach in which
> data is protected when the I/O is submitted by the filesystem is good
> enough for most things. Saves the filesystem people the trouble of
> dealing with it too.
> 
> In reality there are only a handful of applications that would actually
> benefit from an explicit userland API. Mostly in the database
> department. All the potential consumers of an interface I talked to
> wanted to use aio so that's why we've focused our efforts there.
> 
aio is perfectly fine; all I care is to have _any_ way of feeding
protection information into the kernel.

> Both Darrick and I have been busy with other projects the last little
> while. I'll start looking at this again when I'm done with copy
> offload...
> 
Speaking of which, are there any patches?
Doug Gilbert and I are currently discussing LID4 / ROD Token copy
for sg3_utils and the block layer, so any patches would be very
helpful here.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare@...e.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
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/