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 <wm...@netflix.com>
>
> 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 <wm...@netflix.com>
> ---
> 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
> * <hash device>
> * <data block size>
> * <hash block size>
> + * <data start block>
> * <the number of data blocks>
> * <hash start block>
> * <algorithm>
> @@ -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
> =======================
> <version> <dev> <hash_dev>
> <data_block_size> <hash_block_size>
> - <num_data_blocks> <hash_start_block>
> + <data_start_block> <num_data_blocks> <hash_start_block>
> <algorithm> <digest> <salt>
>
> <version>
> @@ -41,6 +41,10 @@ Construction Parameters
> <hash_block_size>
> The size of a hash block in bytes.
>
> +<data_start_block>
> + This is the offset, in <data_block_size>-blocks, from the start of
> data_dev
> + to the first block of the data.
> +
> <num_data_blocks>
> 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
