All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alasdair G Kergon <agk@redhat.com>
To: Thore Sommer <public@thson.de>
Cc: tusharsu@linux.microsoft.com, agk@redhat.com,
	dm-devel@redhat.com, linux-integrity@vger.kernel.org,
	nramas@linux.microsoft.com, snitzer@redhat.com,
	zohar@linux.ibm.com
Subject: Re: [dm-devel] [PATCH 0/7] device mapper target measurements using IMA
Date: Wed, 28 Jul 2021 22:33:50 +0100	[thread overview]
Message-ID: <20210728213350.GA115575@agk-cloud1.hosts.prod.upshift.rdu2.redhat.com> (raw)
In-Reply-To: <20210727101802.779067-1-public@thson.de>

On Tue, Jul 27, 2021 at 12:18:02PM +0200, Thore Sommer wrote:
> How is the measured uuid created? The format seems to be
> "CRYPT-VERITY-UUID-NAME" where UUID is uuid from the verity device and NAME is
> the device mapper name. Does this naming come from the kernel or libcryptsetup?

See libdevmapper.h:
/*
 * Configure default UUID prefix string.
 * Conventionally this is a short capitalised prefix indicating the subsystem
 * that is managing the devices, e.g. "LVM-" or "MPATH-".
 * To support stacks of devices from different subsystems, recursive functions
 * stop recursing if they reach a device with a different prefix.
 */
int dm_set_uuid_prefix(const char *uuid_prefix);


Each device-mapper device may have a uuid of up to 128 characters plus
trailing NUL.  Whichever piece software activates the device assigns the
uuid (so userspace or kernel boot parameters).  By convention each such
piece of software uses a short prefix ending with a hyphen that
identifies that software as the "owner" (manager) of that dm device.
This means each piece of software can easily filter out the devices for
which it is responsible and ignore all the others etc.  It can use the
remainder of the UUID to identify the device uniquely to itself.
Another convention is that when one device is a 'wrapper' of some sort
around another, it may create the uuid by adding its prefix to the uuid
of the device it is wrapping - this might give you stacked prefixes.
When there's a complex one-composed-from-many device structure, suffices
may be used to identify the components.

Think of the 'name' as the human-friendly device name and the uuid as
a software-friendly internal name.

Alasdair


WARNING: multiple messages have this Message-ID (diff)
From: Alasdair G Kergon <agk@redhat.com>
To: Thore Sommer <public@thson.de>
Cc: snitzer@redhat.com, zohar@linux.ibm.com,
	nramas@linux.microsoft.com, dm-devel@redhat.com,
	tusharsu@linux.microsoft.com, linux-integrity@vger.kernel.org,
	agk@redhat.com
Subject: Re: [dm-devel] [PATCH 0/7] device mapper target measurements using IMA
Date: Wed, 28 Jul 2021 22:33:50 +0100	[thread overview]
Message-ID: <20210728213350.GA115575@agk-cloud1.hosts.prod.upshift.rdu2.redhat.com> (raw)
In-Reply-To: <20210727101802.779067-1-public@thson.de>

On Tue, Jul 27, 2021 at 12:18:02PM +0200, Thore Sommer wrote:
> How is the measured uuid created? The format seems to be
> "CRYPT-VERITY-UUID-NAME" where UUID is uuid from the verity device and NAME is
> the device mapper name. Does this naming come from the kernel or libcryptsetup?

See libdevmapper.h:
/*
 * Configure default UUID prefix string.
 * Conventionally this is a short capitalised prefix indicating the subsystem
 * that is managing the devices, e.g. "LVM-" or "MPATH-".
 * To support stacks of devices from different subsystems, recursive functions
 * stop recursing if they reach a device with a different prefix.
 */
int dm_set_uuid_prefix(const char *uuid_prefix);


Each device-mapper device may have a uuid of up to 128 characters plus
trailing NUL.  Whichever piece software activates the device assigns the
uuid (so userspace or kernel boot parameters).  By convention each such
piece of software uses a short prefix ending with a hyphen that
identifies that software as the "owner" (manager) of that dm device.
This means each piece of software can easily filter out the devices for
which it is responsible and ignore all the others etc.  It can use the
remainder of the UUID to identify the device uniquely to itself.
Another convention is that when one device is a 'wrapper' of some sort
around another, it may create the uuid by adding its prefix to the uuid
of the device it is wrapping - this might give you stacked prefixes.
When there's a complex one-composed-from-many device structure, suffices
may be used to identify the components.

Think of the 'name' as the human-friendly device name and the uuid as
a software-friendly internal name.

Alasdair

--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel


  parent reply	other threads:[~2021-07-28 21:34 UTC|newest]

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-13  0:48 [PATCH 0/7] device mapper target measurements using IMA Tushar Sugandhi
2021-07-13  0:48 ` [dm-devel] " Tushar Sugandhi
2021-07-13  0:48 ` [PATCH 1/7] dm: measure data on table load Tushar Sugandhi
2021-07-13  0:48   ` [dm-devel] " Tushar Sugandhi
2021-07-21  2:12   ` Mimi Zohar
2021-07-21  2:12     ` [dm-devel] " Mimi Zohar
2021-07-21 15:42     ` Mike Snitzer
2021-07-21 15:42       ` [dm-devel] " Mike Snitzer
2021-07-21 16:07       ` Mimi Zohar
2021-07-21 16:07         ` [dm-devel] " Mimi Zohar
2021-07-21 21:17         ` Mimi Zohar
2021-07-21 21:17           ` [dm-devel] " Mimi Zohar
2021-07-29 19:58           ` Tushar Sugandhi
2021-07-29 19:58             ` [dm-devel] " Tushar Sugandhi
2021-07-13  0:48 ` [PATCH 2/7] dm: measure data on device resume Tushar Sugandhi
2021-07-13  0:48   ` [dm-devel] " Tushar Sugandhi
2021-07-13  0:49 ` [PATCH 3/7] dm: measure data on device remove Tushar Sugandhi
2021-07-13  0:49   ` [dm-devel] " Tushar Sugandhi
2021-07-13  0:49 ` [PATCH 4/7] dm: measure data on table clear Tushar Sugandhi
2021-07-13  0:49   ` [dm-devel] " Tushar Sugandhi
2021-07-13  0:49 ` [PATCH 5/7] dm: measure data on device rename Tushar Sugandhi
2021-07-13  0:49   ` [dm-devel] " Tushar Sugandhi
2021-07-13  0:49 ` [PATCH 6/7] dm: update target specific status functions to measure data Tushar Sugandhi
2021-07-13  0:49   ` [dm-devel] " Tushar Sugandhi
2021-07-13  1:06   ` Alasdair G Kergon
2021-07-13  1:06     ` [dm-devel] " Alasdair G Kergon
2021-07-14 20:23     ` Tushar Sugandhi
2021-07-14 20:23       ` [dm-devel] " Tushar Sugandhi
2021-07-13  0:49 ` [PATCH 7/7] dm: add documentation for IMA measurement support Tushar Sugandhi
2021-07-13  0:49   ` [dm-devel] " Tushar Sugandhi
2021-07-21  2:33   ` Mimi Zohar
2021-07-21  2:33     ` [dm-devel] " Mimi Zohar
2021-07-24  7:25     ` Tushar Sugandhi
2021-07-24  7:25       ` [dm-devel] " Tushar Sugandhi
2021-07-26 16:33       ` Mimi Zohar
2021-07-26 16:33         ` [dm-devel] " Mimi Zohar
2021-07-26 18:28         ` Tushar Sugandhi
2021-07-26 18:28           ` [dm-devel] " Tushar Sugandhi
2021-07-14 11:32 ` [dm-devel] [PATCH 0/7] device mapper target measurements using IMA Thore Sommer
2021-07-14 11:32   ` Thore Sommer
2021-07-14 20:20   ` Tushar Sugandhi
2021-07-14 20:20     ` Tushar Sugandhi
2021-07-27 10:18     ` Thore Sommer
2021-07-27 10:18       ` Thore Sommer
2021-07-27 20:33       ` Alasdair G Kergon
2021-07-27 20:33         ` Alasdair G Kergon
2021-07-28  3:10         ` Tushar Sugandhi
2021-07-28  3:10           ` Tushar Sugandhi
2021-07-28 17:14           ` Thore Sommer
2021-07-28 17:14             ` Thore Sommer
2021-07-29 17:32             ` Tushar Sugandhi
2021-07-29 17:32               ` Tushar Sugandhi
2021-07-28 17:34         ` Thore Sommer
2021-07-28 17:34           ` Thore Sommer
2021-07-28 21:33       ` Alasdair G Kergon [this message]
2021-07-28 21:33         ` Alasdair G Kergon
2021-08-02 10:45         ` Thore Sommer
2021-08-02 10:45           ` Thore Sommer
2021-07-29 19:24       ` Tushar Sugandhi
2021-07-29 19:24         ` Tushar Sugandhi
2021-08-02 10:38         ` Thore Sommer
2021-08-02 10:38           ` Thore Sommer
2021-07-20 21:27 ` Mike Snitzer
2021-07-20 21:27   ` [dm-devel] " Mike Snitzer
2021-07-24  6:57   ` Tushar Sugandhi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210728213350.GA115575@agk-cloud1.hosts.prod.upshift.rdu2.redhat.com \
    --to=agk@redhat.com \
    --cc=dm-devel@redhat.com \
    --cc=linux-integrity@vger.kernel.org \
    --cc=nramas@linux.microsoft.com \
    --cc=public@thson.de \
    --cc=snitzer@redhat.com \
    --cc=tusharsu@linux.microsoft.com \
    --cc=zohar@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.