linux-kernel - Re: [dm-devel] [PATCH v2 1/2] dm: verity support data device offset (Linux 3.4.7)

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] [day] [month] [year] [list]

Date:	Fri, 10 Aug 2012 01:00:50 +0000
From:	Wesley Miaw <wmiaw@...flix.com>
To:	Alasdair G Kergon <agk@...hat.com>
CC:	Milan Broz <mbroz@...hat.com>,
	Mikulas Patocka <mpatocka@...hat.com>,
	device-mapper development <dm-devel@...hat.com>,
	"msb@...gle.com" <msb@...gle.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Will Drewry™ <w@...gle.com>
Subject: Re: [dm-devel] [PATCH v2 1/2] dm: verity support data device	offset
 (Linux 3.4.7)

On Aug 8, 2012, at 7:04 PM, Alasdair G Kergon wrote:
> 
> However, first you need to address the second part of Mikulas's email,
> namely to make the case for these changes rather than making no kernel
> changes and instead stacking the verity target over a linear target.
> 
> To put this another way, your patch offers an alternative way to do
> something we think the existing kernel can already do, so you need to
> advance some reasons why you believe the new alternative method is worth
> adding to the kernel and explain this in the patch header.

I'm afraid for some reason I didn't get Mikulas's first email, only the reply from Milan which must have been an incomplete quote of Mikulas's text.

For my part, I approached this as porting my existing code to the new dm-verity implementation included in Linux 3.4. The previous code used a data offset as this was convenient and directly supported the block device image format I put together back then.

However I can indeed accomplish what I need using linear, it's just a bit more code. I am not able to measure any runtime performance difference. The primary benefit I can see for is the reduced kernel footprint if the linear target does not need to be included (and my corresponding setup code is about 1/3 smaller). With my cross-compiled kernel the savings is ~1KB; this is obviously a very small benefit.

So I would defer to others on this. While supporting the data offset would be convenient and match well with my specific use case I can live without it and I don't think the size cost is significant enough to matter. I expect to get some feedback from other developers in the coming months regarding my Linux 3.4 integration but I doubt it would change my current opinion on the matter.

Thanks,
--
Wesley Miaw
Download attachment "signature.asc" of type "application/pgp-signature" (496 bytes)