ipe: add support for dm-verity as a trust provider

Allows author of IPE policy to indicate trust for a singular dm-verity
volume, identified by roothash, through "dmverity_roothash" and all
signed and validated dm-verity volumes, through "dmverity_signature".

Signed-off-by: Deven Bowers <deven.desai@linux.microsoft.com>
Signed-off-by: Fan Wu <wufan@linux.microsoft.com>
[PM: fixed some line length issues in the comments]
Signed-off-by: Paul Moore <paul@paul-moore.com>

1 files changed, 12 insertions, 11 deletions

diff --git a/security/security.c b/security/security.c
index c7feaa885a0e..3160a0173581 100644
--- a/security/security.c
+++ b/security/security.c
@@ -5739,17 +5739,18 @@ EXPORT_SYMBOL(security_bdev_free);
  * Please note that the new hook should be invoked every time the security
  * information is updated to keep these data current. For example, in dm-verity,
  * if the mapping table is reloaded and configured to use a different dm-verity
- * target with a new roothash and signing information, the previously stored data
- * in the LSM blob will become obsolete. It is crucial to re-invoke the hook to
- * refresh these data and ensure they are up to date. This necessity arises from
- * the design of device-mapper, where a device-mapper device is first created, and
- * then targets are subsequently loaded into it. These targets can be modified
- * multiple times during the device's lifetime. Therefore, while the LSM blob is
- * allocated during the creation of the block device, its actual contents are
- * not initialized at this stage and can change substantially over time. This
- * includes alterations from data that the LSMs 'trusts' to those they do not,
- * making it essential to handle these changes correctly. Failure to address
- * this dynamic aspect could potentially allow for bypassing LSM checks.
+ * target with a new roothash and signing information, the previously stored
+ * data in the LSM blob will become obsolete. It is crucial to re-invoke the
+ * hook to refresh these data and ensure they are up to date. This necessity
+ * arises from the design of device-mapper, where a device-mapper device is
+ * first created, and then targets are subsequently loaded into it. These
+ * targets can be modified multiple times during the device's lifetime.
+ * Therefore, while the LSM blob is allocated during the creation of the block
+ * device, its actual contents are not initialized at this stage and can change
+ * substantially over time. This includes alterations from data that the LSMs
+ * 'trusts' to those they do not, making it essential to handle these changes
+ * correctly. Failure to address this dynamic aspect could potentially allow
+ * for bypassing LSM checks.
  *
  * Return: Returns 0 on success, negative values on failure.
  */