Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758623Ab2HHSrH (ORCPT ); Wed, 8 Aug 2012 14:47:07 -0400 Received: from mx1.redhat.com ([209.132.183.28]:50458 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753374Ab2HHSrE (ORCPT ); Wed, 8 Aug 2012 14:47:04 -0400 Date: Wed, 8 Aug 2012 14:46:57 -0400 (EDT) From: Mikulas Patocka X-X-Sender: mpatocka@file.rdu.redhat.com To: device-mapper development cc: Alasdair Kergon , "msb@google.com" , "linux-kernel@vger.kernel.org" , =?Windows-1252?Q?Will_Drewry=99?= Subject: Re: [dm-devel] [PATCH] dm: verity support data device offset (Linux 3.4.7) In-Reply-To: <8893CF66-2E2C-4D8F-9239-E38BE55716AE@netflix.com> Message-ID: References: <8893CF66-2E2C-4D8F-9239-E38BE55716AE@netflix.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 6241 Lines: 162 Hi The problem with the patch is that it changes interface to the userspace tool. The userspace tool veritysetup already exists in recent cryptsetup package, so we can't change the interface - you should change the patch so that the starting data block is the last argument and the argument is optional - so that it is compatible with the existing userspace too. Another thing --- do we need this patch at all? You can create a dm-linear device and stack existing dm-verity on the top of it to get the same effect of changing data starting block. Is there some reason why you can't use dm-linear device and why you need this patch? Mikulas On Wed, 8 Aug 2012, Wesley Miaw wrote: > From: Wesley Miaw > > Add data device start block index to dm-verity target parameters to support > verity targets where the data does not begin at sector 0 of the block device. > Also fix the hash block index computation so it takes into account data offsets. > > Signed-off-by: Wesley Miaw > --- > Documentation/device-mapper/verity.txt | 8 ++++- > drivers/md/dm-verity.c | 32 +++++++++++++++-------- > 2 files changed, 27 insertions(+), 13 deletions(-) > --- a/drivers/md/dm-verity.c 2012-08-07 16:03:03.778759000 -0700 > +++ b/drivers/md/dm-verity.c 2012-08-07 17:32:02.130176956 -0700 > @@ -491,7 +491,7 @@ static int verity_map(struct dm_target * > io->bio = bio; > io->orig_bi_end_io = bio->bi_end_io; > io->orig_bi_private = bio->bi_private; > - io->block = bio->bi_sector >> (v->data_dev_block_bits - SECTOR_SHIFT); > + io->block = (bio->bi_sector - v->data_start) >> (v->data_dev_block_bits - SECTOR_SHIFT); > io->n_blocks = bio->bi_size >> v->data_dev_block_bits; > > bio->bi_end_io = verity_end_io; > @@ -641,6 +641,7 @@ static void verity_dtr(struct dm_target > * > * > * > + * > * > * > * > @@ -671,8 +672,8 @@ static int verity_ctr(struct dm_target * > goto bad; > } > > - if (argc != 10) { > - ti->error = "Invalid argument count: exactly 10 arguments required"; > + if (argc != 11) { > + ti->error = "Invalid argument count: exactly 11 arguments required"; > r = -EINVAL; > goto bad; > } > @@ -718,6 +719,15 @@ static int verity_ctr(struct dm_target * > v->hash_dev_block_bits = ffs(num) - 1; > > if (sscanf(argv[5], "%llu%c", &num_ll, &dummy) != 1 || > + num_ll << (v->data_dev_block_bits - SECTOR_SHIFT) != > + (sector_t)num_ll << (v->data_dev_block_bits - SECTOR_SHIFT)) { > + ti->error = "Invalid data start"; > + r = -EINVAL; > + goto bad; > + } > + v->data_start = num_ll << (v->data_dev_block_bits - SECTOR_SHIFT); > + > + if (sscanf(argv[6], "%llu%c", &num_ll, &dummy) != 1 || > num_ll << (v->data_dev_block_bits - SECTOR_SHIFT) != > (sector_t)num_ll << (v->data_dev_block_bits - SECTOR_SHIFT)) { > ti->error = "Invalid data blocks"; > @@ -732,7 +742,7 @@ static int verity_ctr(struct dm_target * > goto bad; > } > > - if (sscanf(argv[6], "%llu%c", &num_ll, &dummy) != 1 || > + if (sscanf(argv[7], "%llu%c", &num_ll, &dummy) != 1 || > num_ll << (v->hash_dev_block_bits - SECTOR_SHIFT) != > (sector_t)num_ll << (v->hash_dev_block_bits - SECTOR_SHIFT)) { > ti->error = "Invalid hash start"; > @@ -741,7 +751,7 @@ static int verity_ctr(struct dm_target * > } > v->hash_start = num_ll; > > - v->alg_name = kstrdup(argv[7], GFP_KERNEL); > + v->alg_name = kstrdup(argv[8], GFP_KERNEL); > if (!v->alg_name) { > ti->error = "Cannot allocate algorithm name"; > r = -ENOMEM; > @@ -770,23 +780,23 @@ static int verity_ctr(struct dm_target * > r = -ENOMEM; > goto bad; > } > - if (strlen(argv[8]) != v->digest_size * 2 || > - hex2bin(v->root_digest, argv[8], v->digest_size)) { > + if (strlen(argv[9]) != v->digest_size * 2 || > + hex2bin(v->root_digest, argv[9], v->digest_size)) { > ti->error = "Invalid root digest"; > r = -EINVAL; > goto bad; > } > > - if (strcmp(argv[9], "-")) { > - v->salt_size = strlen(argv[9]) / 2; > + if (strcmp(argv[10], "-")) { > + v->salt_size = strlen(argv[10]) / 2; > v->salt = kmalloc(v->salt_size, GFP_KERNEL); > if (!v->salt) { > ti->error = "Cannot allocate salt"; > r = -ENOMEM; > goto bad; > } > - if (strlen(argv[9]) != v->salt_size * 2 || > - hex2bin(v->salt, argv[9], v->salt_size)) { > + if (strlen(argv[10]) != v->salt_size * 2 || > + hex2bin(v->salt, argv[10], v->salt_size)) { > ti->error = "Invalid salt"; > r = -EINVAL; > goto bad; > --- a/Documentation/device-mapper/verity.txt 2012-08-08 11:02:48.558883756 -0700 > +++ b/Documentation/device-mapper/verity.txt 2012-08-08 11:13:01.259982498 -0700 > @@ -9,7 +9,7 @@ Construction Parameters > ======================= > > > - > + > > > > @@ -41,6 +41,10 @@ Construction Parameters > > The size of a hash block in bytes. > > + > + This is the offset, in -blocks, from the start of data_dev > + to the first block of the data. > + > > The number of data blocks on the data device. Additional blocks are > inaccessible. You can place hashes to the same partition as data, in this > @@ -136,7 +140,7 @@ Example > ======= > Set up a device: > # dmsetup create vroot --readonly --table \ > - "0 2097152 verity 1 /dev/sda1 /dev/sda2 4096 4096 262144 1 sha256 "\ > + "0 2097152 verity 1 /dev/sda1 /dev/sda2 4096 4096 0 262144 1 sha256 "\ > "4392712ba01368efdf14b05c76f9e4df0d53664630b5d48632ed17a137f39076 "\ > "1234000000000000000000000000000000000000000000000000000000000000" > > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/