Documentation/admin-guide/device-mapper/dm-ima.rst

   1 ======
   2 dm-ima
   3 ======
   4
   5 For a given system, various external services/infrastructure tools
   6 (including the attestation service) interact with it - both during the
   7 setup and during rest of the system run-time.  They share sensitive data
   8 and/or execute critical workload on that system.  The external services
   9 may want to verify the current run-time state of the relevant kernel
  10 subsystems before fully trusting the system with business-critical
  11 data/workload.
  12
  13 Device mapper plays a critical role on a given system by providing
  14 various important functionalities to the block devices using various
  15 target types like crypt, verity, integrity etc.  Each of these target
  16 types’ functionalities can be configured with various attributes.
  17 The attributes chosen to configure these target types can significantly
  18 impact the security profile of the block device, and in-turn, of the
  19 system itself.  For instance, the type of encryption algorithm and the
  20 key size determines the strength of encryption for a given block device.
  21
  22 Therefore, verifying the current state of various block devices as well
  23 as their various target attributes is crucial for external services before
  24 fully trusting the system with business-critical data/workload.
  25
  26 IMA kernel subsystem provides the necessary functionality for
  27 device mapper to measure the state and configuration of
  28 various block devices -
  29
  30 - by device mapper itself, from within the kernel,
  31 - in a tamper resistant way,
  32 - and re-measured - triggered on state/configuration change.
  33
  34 Setting the IMA Policy:
  35 =======================
  36 For IMA to measure the data on a given system, the IMA policy on the
  37 system needs to be updated to have following line, and the system needs
  38 to be restarted for the measurements to take effect.
  39
  40 ::
  41
  42  /etc/ima/ima-policy
  43     measure func=CRITICAL_DATA label=device-mapper template=ima-buf
  44
  45 The measurements will be reflected in the IMA logs, which are located at:
  46
  47 ::
  48
  49  /sys/kernel/security/integrity/ima/ascii_runtime_measurements
  50  /sys/kernel/security/integrity/ima/binary_runtime_measurements
  51
  52 Then IMA ASCII measurement log has the following format:
  53
  54 ::
  55
  56  <PCR> <TEMPLATE_DATA_DIGEST> <TEMPLATE_NAME> <TEMPLATE_DATA>
  57
  58  PCR := Platform Configuration Register, in which the values are registered.
  59        This is applicable if TPM chip is in use.
  60
  61  TEMPLATE_DATA_DIGEST := Template data digest of the IMA record.
  62  TEMPLATE_NAME := Template name that registered the integrity value (e.g. ima-buf).
  63
  64  TEMPLATE_DATA := <ALG> ":" <EVENT_DIGEST> <EVENT_NAME> <EVENT_DATA>
  65                   It contains data for the specific event to be measured,
  66                   in a given template data format.
  67
  68  ALG := Algorithm to compute event digest
  69  EVENT_DIGEST := Digest of the event data
  70  EVENT_NAME := Description of the event (e.g. 'dm_table_load').
  71  EVENT_DATA := The event data to be measured.
  72
  73 |
  74
  75 | *NOTE #1:*
  76 | The DM target data measured by IMA subsystem can alternatively
  77  be queried from userspace by setting DM_IMA_MEASUREMENT_FLAG with
  78  DM_TABLE_STATUS_CMD.
  79
  80 |
  81
  82 | *NOTE #2:*
  83 | The Kernel configuration CONFIG_IMA_DISABLE_HTABLE allows measurement of duplicate records.
  84 | To support recording duplicate IMA events in the IMA log, the Kernel needs to be configured with
  85  CONFIG_IMA_DISABLE_HTABLE=y.
  86
  87 Supported Device States:
  88 ========================
  89 Following device state changes will trigger IMA measurements:
  90
  91  1. Table load
  92  #. Device resume
  93  #. Device remove
  94  #. Table clear
  95  #. Device rename
  96
  97 1. Table load:
  98 ---------------
  99 When a new table is loaded in a device's inactive table slot,
 100 the device information and target specific details from the
 101 targets in the table are measured.
 102
 103 The IMA measurement log has the following format for 'dm_table_load':
 104
 105 ::
 106
 107  EVENT_NAME := "dm_table_load"
 108  EVENT_DATA := <dm_version_str> ";" <device_metadata> ";" <table_load_data>
 109
 110  dm_version_str := "dm_version=" <N> "." <N> "." <N>
 111                   Same as Device Mapper driver version.
 112  device_metadata := <device_name> "," <device_uuid> "," <device_major> "," <device_minor> ","
 113                    <minor_count> "," <num_device_targets> ";"
 114
 115  device_name := "name=" <dm-device-name>
 116  device_uuid := "uuid=" <dm-device-uuid>
 117  device_major := "major=" <N>
 118  device_minor := "minor=" <N>
 119  minor_count := "minor_count=" <N>
 120  num_device_targets := "num_targets=" <N>
 121  dm-device-name := Name of the device. If it contains special characters like '\', ',', ';',
 122                    they are prefixed with '\'.
 123  dm-device-uuid := UUID of the device. If it contains special characters like '\', ',', ';',
 124                    they are prefixed with '\'.
 125
 126  table_load_data := <target_data>
 127                     Represents the data (as name=value pairs) from various targets in the table,
 128                     which is being loaded into the DM device's inactive table slot.
 129  target_data := <target_data_row> | <target_data><target_data_row>
 130
 131  target_data_row := <target_index> "," <target_begin> "," <target_len> "," <target_name> ","
 132                     <target_version> "," <target_attributes> ";"
 133  target_index := "target_index=" <N>
 134                  Represents nth target in the table (from 0 to N-1 targets specified in <num_device_targets>)
 135                  If all the data for N targets doesn't fit in the given buffer - then the data that fits
 136                  in the buffer (say from target 0 to x) is measured in a given IMA event.
 137                  The remaining data from targets x+1 to N-1 is measured in the subsequent IMA events,
 138                  with the same format as that of 'dm_table_load'
 139                  i.e. <dm_version_str> ";" <device_metadata> ";" <table_load_data>.
 140
 141  target_begin := "target_begin=" <N>
 142  target_len := "target_len=" <N>
 143  target_name := Name of the target. 'linear', 'crypt', 'integrity' etc.
 144                 The targets that are supported for IMA measurements are documented below in the
 145                 'Supported targets' section.
 146  target_version := "target_version=" <N> "." <N> "." <N>
 147  target_attributes := Data containing comma separated list of name=value pairs of target specific attributes.
 148
 149  For instance, if a linear device is created with the following table entries,
 150   # dmsetup create linear1
 151   0 2 linear /dev/loop0 512
 152   2 2 linear /dev/loop0 512
 153   4 2 linear /dev/loop0 512
 154   6 2 linear /dev/loop0 512
 155
 156  Then IMA ASCII measurement log will have the following entry:
 157  (converted from ASCII to text for readability)
 158
 159  10 a8c5ff755561c7a28146389d1514c318592af49a ima-buf sha256:4d73481ecce5eadba8ab084640d85bb9ca899af4d0a122989252a76efadc5b72
 160  dm_table_load
 161  dm_version=4.45.0;
 162  name=linear1,uuid=,major=253,minor=0,minor_count=1,num_targets=4;
 163  target_index=0,target_begin=0,target_len=2,target_name=linear,target_version=1.4.0,device_name=7:0,start=512;
 164  target_index=1,target_begin=2,target_len=2,target_name=linear,target_version=1.4.0,device_name=7:0,start=512;
 165  target_index=2,target_begin=4,target_len=2,target_name=linear,target_version=1.4.0,device_name=7:0,start=512;
 166  target_index=3,target_begin=6,target_len=2,target_name=linear,target_version=1.4.0,device_name=7:0,start=512;
 167
 168 2. Device resume:
 169 ------------------
 170 When a suspended device is resumed, the device information and the hash of the
 171 data from previous load of an active table are measured.
 172
 173 The IMA measurement log has the following format for 'dm_device_resume':
 174
 175 ::
 176
 177  EVENT_NAME := "dm_device_resume"
 178  EVENT_DATA := <dm_version_str> ";" <device_metadata> ";" <active_table_hash> ";" <current_device_capacity> ";"
 179
 180  dm_version_str := As described in the 'Table load' section above.
 181  device_metadata := As described in the 'Table load' section above.
 182  active_table_hash := "active_table_hash=" <table_hash_alg> ":" <table_hash>
 183                       Rerpresents the hash of the IMA data being measured for the
 184                       active table for the device.
 185  table_hash_alg := Algorithm used to compute the hash.
 186  table_hash := Hash of the (<dm_version_str> ";" <device_metadata> ";" <table_load_data> ";")
 187                as described in the 'dm_table_load' above.
 188                Note: If the table_load data spans across multiple IMA 'dm_table_load'
 189                events for a given device, the hash is computed combining all the event data
 190                i.e. (<dm_version_str> ";" <device_metadata> ";" <table_load_data> ";")
 191                across all those events.
 192  current_device_capacity := "current_device_capacity=" <N>
 193
 194  For instance, if a linear device is resumed with the following command,
 195  #dmsetup resume linear1
 196
 197  then IMA ASCII measurement log will have an entry with:
 198  (converted from ASCII to text for readability)
 199
 200  10 56c00cc062ffc24ccd9ac2d67d194af3282b934e ima-buf sha256:e7d12c03b958b4e0e53e7363a06376be88d98a1ac191fdbd3baf5e4b77f329b6
 201  dm_device_resume
 202  dm_version=4.45.0;
 203  name=linear1,uuid=,major=253,minor=0,minor_count=1,num_targets=4;
 204  active_table_hash=sha256:4d73481ecce5eadba8ab084640d85bb9ca899af4d0a122989252a76efadc5b72;current_device_capacity=8;
 205
 206 3. Device remove:
 207 ------------------
 208 When a device is removed, the device information and a sha256 hash of the
 209 data from an active and inactive table are measured.
 210
 211 The IMA measurement log has the following format for 'dm_device_remove':
 212
 213 ::
 214
 215  EVENT_NAME := "dm_device_remove"
 216  EVENT_DATA := <dm_version_str> ";" <device_active_metadata> ";" <device_inactive_metadata> ";"
 217                <active_table_hash> "," <inactive_table_hash> "," <remove_all> ";" <current_device_capacity> ";"
 218
 219  dm_version_str := As described in the 'Table load' section above.
 220  device_active_metadata := Device metadata that reflects the currently loaded active table.
 221                            The format is same as 'device_metadata' described in the 'Table load' section above.
 222  device_inactive_metadata := Device metadata that reflects the inactive table.
 223                              The format is same as 'device_metadata' described in the 'Table load' section above.
 224  active_table_hash := Hash of the currently loaded active table.
 225                       The format is same as 'active_table_hash' described in the 'Device resume' section above.
 226  inactive_table_hash :=  Hash of the inactive table.
 227                          The format is same as 'active_table_hash' described in the 'Device resume' section above.
 228  remove_all := "remove_all=" <yes_no>
 229  yes_no := "y" | "n"
 230  current_device_capacity := "current_device_capacity=" <N>
 231
 232  For instance, if a linear device is removed with the following command,
 233   #dmsetup remove l1
 234
 235  then IMA ASCII measurement log will have the following entry:
 236  (converted from ASCII to text for readability)
 237
 238  10 790e830a3a7a31590824ac0642b3b31c2d0e8b38 ima-buf sha256:ab9f3c959367a8f5d4403d6ce9c3627dadfa8f9f0e7ec7899299782388de3840
 239  dm_device_remove
 240  dm_version=4.45.0;
 241  device_active_metadata=name=l1,uuid=,major=253,minor=2,minor_count=1,num_targets=2;
 242  device_inactive_metadata=name=l1,uuid=,major=253,minor=2,minor_count=1,num_targets=1;
 243  active_table_hash=sha256:4a7e62efaebfc86af755831998b7db6f59b60d23c9534fb16a4455907957953a,
 244  inactive_table_hash=sha256:9d79c175bc2302d55a183e8f50ad4bafd60f7692fd6249e5fd213e2464384b86,remove_all=n;
 245  current_device_capacity=2048;
 246
 247 4. Table clear:
 248 ----------------
 249 When an inactive table is cleared from the device, the device information and a sha256 hash of the
 250 data from an inactive table are measured.
 251
 252 The IMA measurement log has the following format for 'dm_table_clear':
 253
 254 ::
 255
 256  EVENT_NAME := "dm_table_clear"
 257  EVENT_DATA := <dm_version_str> ";" <device_inactive_metadata> ";" <inactive_table_hash> ";" <current_device_capacity> ";"
 258
 259  dm_version_str := As described in the 'Table load' section above.
 260  device_inactive_metadata := Device metadata that was captured during the load time inactive table being cleared.
 261                              The format is same as 'device_metadata' described in the 'Table load' section above.
 262  inactive_table_hash := Hash of the inactive table being cleared from the device.
 263                         The format is same as 'active_table_hash' described in the 'Device resume' section above.
 264  current_device_capacity := "current_device_capacity=" <N>
 265
 266  For instance, if a linear device's inactive table is cleared,
 267   #dmsetup clear l1
 268
 269  then IMA ASCII measurement log will have an entry with:
 270  (converted from ASCII to text for readability)
 271
 272  10 77d347408f557f68f0041acb0072946bb2367fe5 ima-buf sha256:42f9ca22163fdfa548e6229dece2959bc5ce295c681644240035827ada0e1db5
 273  dm_table_clear
 274  dm_version=4.45.0;
 275  name=l1,uuid=,major=253,minor=2,minor_count=1,num_targets=1;
 276  inactive_table_hash=sha256:75c0dc347063bf474d28a9907037eba060bfe39d8847fc0646d75e149045d545;current_device_capacity=1024;
 277
 278 5. Device rename:
 279 ------------------
 280 When an device's NAME or UUID is changed, the device information and the new NAME and UUID
 281 are measured.
 282
 283 The IMA measurement log has the following format for 'dm_device_rename':
 284
 285 ::
 286
 287  EVENT_NAME := "dm_device_rename"
 288  EVENT_DATA := <dm_version_str> ";" <device_active_metadata> ";" <new_device_name> "," <new_device_uuid> ";" <current_device_capacity> ";"
 289
 290  dm_version_str := As described in the 'Table load' section above.
 291  device_active_metadata := Device metadata that reflects the currently loaded active table.
 292                            The format is same as 'device_metadata' described in the 'Table load' section above.
 293  new_device_name := "new_name=" <dm-device-name>
 294  dm-device-name := Same as <dm-device-name> described in 'Table load' section above
 295  new_device_uuid := "new_uuid=" <dm-device-uuid>
 296  dm-device-uuid := Same as <dm-device-uuid> described in 'Table load' section above
 297  current_device_capacity := "current_device_capacity=" <N>
 298
 299  E.g 1: if a linear device's name is changed with the following command,
 300   #dmsetup rename linear1 --setuuid 1234-5678
 301
 302  then IMA ASCII measurement log will have an entry with:
 303  (converted from ASCII to text for readability)
 304
 305  10 8b0423209b4c66ac1523f4c9848c9b51ee332f48 ima-buf sha256:6847b7258134189531db593e9230b257c84f04038b5a18fd2e1473860e0569ac
 306  dm_device_rename
 307  dm_version=4.45.0;
 308  name=linear1,uuid=,major=253,minor=2,minor_count=1,num_targets=1;new_name=linear1,new_uuid=1234-5678;
 309  current_device_capacity=1024;
 310
 311  E.g 2:  if a linear device's name is changed with the following command,
 312   # dmsetup rename linear1 linear=2
 313
 314  then IMA ASCII measurement log will have an entry with:
 315  (converted from ASCII to text for readability)
 316
 317  10 bef70476b99c2bdf7136fae033aa8627da1bf76f ima-buf sha256:8c6f9f53b9ef9dc8f92a2f2cca8910e622543d0f0d37d484870cb16b95111402
 318  dm_device_rename
 319  dm_version=4.45.0;
 320  name=linear1,uuid=1234-5678,major=253,minor=2,minor_count=1,num_targets=1;
 321  new_name=linear\=2,new_uuid=1234-5678;
 322  current_device_capacity=1024;
 323
 324 Supported targets:
 325 ==================
 326
 327 Following targets are supported to measure their data using IMA:
 328
 329  1. cache
 330  #. crypt
 331  #. integrity
 332  #. linear
 333  #. mirror
 334  #. multipath
 335  #. raid
 336  #. snapshot
 337  #. striped
 338  #. verity
 339
 340 1. cache
 341 ---------
 342 The 'target_attributes' (described as part of EVENT_DATA in 'Table load'
 343 section above) has the following data format for 'cache' target.
 344
 345 ::
 346
 347  target_attributes := <target_name> "," <target_version> "," <metadata_mode> "," <cache_metadata_device> ","
 348                       <cache_device> "," <cache_origin_device> "," <writethrough> "," <writeback> ","
 349                       <passthrough> "," <no_discard_passdown> ";"
 350
 351  target_name := "target_name=cache"
 352  target_version := "target_version=" <N> "." <N> "." <N>
 353  metadata_mode := "metadata_mode=" <cache_metadata_mode>
 354  cache_metadata_mode := "fail" | "ro" | "rw"
 355  cache_device := "cache_device=" <cache_device_name_string>
 356  cache_origin_device := "cache_origin_device=" <cache_origin_device_string>
 357  writethrough := "writethrough=" <yes_no>
 358  writeback := "writeback=" <yes_no>
 359  passthrough := "passthrough=" <yes_no>
 360  no_discard_passdown := "no_discard_passdown=" <yes_no>
 361  yes_no := "y" | "n"
 362
 363  E.g.
 364  When a 'cache' target is loaded, then IMA ASCII measurement log will have an entry
 365  similar to the following, depicting what 'cache' attributes are measured in EVENT_DATA
 366  for 'dm_table_load' event.
 367  (converted from ASCII to text for readability)
 368
 369  dm_version=4.45.0;name=cache1,uuid=cache_uuid,major=253,minor=2,minor_count=1,num_targets=1;
 370  target_index=0,target_begin=0,target_len=28672,target_name=cache,target_version=2.2.0,metadata_mode=rw,
 371  cache_metadata_device=253:4,cache_device=253:3,cache_origin_device=253:5,writethrough=y,writeback=n,
 372  passthrough=n,metadata2=y,no_discard_passdown=n;
 373
 374
 375 2. crypt
 376 ---------
 377 The 'target_attributes' (described as part of EVENT_DATA in 'Table load'
 378 section above) has the following data format for 'crypt' target.
 379
 380 ::
 381
 382  target_attributes := <target_name> "," <target_version> "," <allow_discards> "," <same_cpu_crypt> ","
 383                       <submit_from_crypt_cpus> "," <no_read_workqueue> "," <no_write_workqueue> ","
 384                       <iv_large_sectors> "," <iv_large_sectors> "," [<integrity_tag_size> ","] [<cipher_auth> ","]
 385                       [<sector_size> ","] [<cipher_string> ","] <key_size> "," <key_parts> ","
 386                       <key_extra_size> "," <key_mac_size> ";"
 387
 388  target_name := "target_name=crypt"
 389  target_version := "target_version=" <N> "." <N> "." <N>
 390  allow_discards := "allow_discards=" <yes_no>
 391  same_cpu_crypt := "same_cpu_crypt=" <yes_no>
 392  submit_from_crypt_cpus := "submit_from_crypt_cpus=" <yes_no>
 393  no_read_workqueue := "no_read_workqueue=" <yes_no>
 394  no_write_workqueue := "no_write_workqueue=" <yes_no>
 395  iv_large_sectors := "iv_large_sectors=" <yes_no>
 396  integrity_tag_size := "integrity_tag_size=" <N>
 397  cipher_auth := "cipher_auth=" <string>
 398  sector_size := "sector_size="  <N>
 399  cipher_string := "cipher_string="
 400  key_size := "key_size="  <N>
 401  key_parts := "key_parts="  <N>
 402  key_extra_size := "key_extra_size="  <N>
 403  key_mac_size := "key_mac_size="  <N>
 404  yes_no := "y" | "n"
 405
 406  E.g.
 407  When a 'crypt' target is loaded, then IMA ASCII measurement log will have an entry
 408  similar to the following, depicting what 'crypt' attributes are measured in EVENT_DATA
 409  for 'dm_table_load' event.
 410  (converted from ASCII to text for readability)
 411
 412  dm_version=4.45.0;
 413  name=crypt1,uuid=crypt_uuid1,major=253,minor=0,minor_count=1,num_targets=1;
 414  target_index=0,target_begin=0,target_len=1953125,target_name=crypt,target_version=1.23.0,
 415  allow_discards=y,same_cpu=n,submit_from_crypt_cpus=n,no_read_workqueue=n,no_write_workqueue=n,
 416  iv_large_sectors=n,cipher_string=aes-xts-plain64,key_size=32,key_parts=1,key_extra_size=0,key_mac_size=0;
 417
 418 3. integrity
 419 -------------
 420 The 'target_attributes' (described as part of EVENT_DATA in 'Table load'
 421 section above) has the following data format for 'integrity' target.
 422
 423 ::
 424
 425  target_attributes := <target_name> "," <target_version> "," <dev_name> "," <start>
 426                       <tag_size> "," <mode> "," [<meta_device> ","] [<block_size> ","] <recalculate> ","
 427                       <allow_discards> "," <fix_padding> "," <fix_hmac> "," <legacy_recalculate> ","
 428                       <journal_sectors> "," <interleave_sectors> "," <buffer_sectors> ";"
 429
 430  target_name := "target_name=integrity"
 431  target_version := "target_version=" <N> "." <N> "." <N>
 432  dev_name := "dev_name=" <device_name_str>
 433  start := "start=" <N>
 434  tag_size := "tag_size=" <N>
 435  mode := "mode=" <integrity_mode_str>
 436  integrity_mode_str := "J" | "B" | "D" | "R"
 437  meta_device := "meta_device=" <meta_device_str>
 438  block_size := "block_size=" <N>
 439  recalculate := "recalculate=" <yes_no>
 440  allow_discards := "allow_discards=" <yes_no>
 441  fix_padding := "fix_padding=" <yes_no>
 442  fix_hmac := "fix_hmac=" <yes_no>
 443  legacy_recalculate := "legacy_recalculate=" <yes_no>
 444  journal_sectors := "journal_sectors=" <N>
 445  interleave_sectors := "interleave_sectors=" <N>
 446  buffer_sectors := "buffer_sectors=" <N>
 447  yes_no := "y" | "n"
 448
 449  E.g.
 450  When a 'integrity' target is loaded, then IMA ASCII measurement log will have an entry
 451  similar to the following, depicting what 'integrity' attributes are measured in EVENT_DATA
 452  for 'dm_table_load' event.
 453  (converted from ASCII to text for readability)
 454
 455  dm_version=4.45.0;
 456  name=integrity1,uuid=,major=253,minor=1,minor_count=1,num_targets=1;
 457  target_index=0,target_begin=0,target_len=7856,target_name=integrity,target_version=1.10.0,
 458  dev_name=253:0,start=0,tag_size=32,mode=J,recalculate=n,allow_discards=n,fix_padding=n,
 459  fix_hmac=n,legacy_recalculate=n,journal_sectors=88,interleave_sectors=32768,buffer_sectors=128;
 460
 461
 462 4. linear
 463 ----------
 464 The 'target_attributes' (described as part of EVENT_DATA in 'Table load'
 465 section above) has the following data format for 'linear' target.
 466
 467 ::
 468
 469  target_attributes := <target_name> "," <target_version> "," <device_name> <,> <start> ";"
 470
 471  target_name := "target_name=linear"
 472  target_version := "target_version=" <N> "." <N> "." <N>
 473  device_name := "device_name=" <linear_device_name_str>
 474  start := "start=" <N>
 475
 476  E.g.
 477  When a 'linear' target is loaded, then IMA ASCII measurement log will have an entry
 478  similar to the following, depicting what 'linear' attributes are measured in EVENT_DATA
 479  for 'dm_table_load' event.
 480  (converted from ASCII to text for readability)
 481
 482  dm_version=4.45.0;
 483  name=linear1,uuid=linear_uuid1,major=253,minor=2,minor_count=1,num_targets=1;
 484  target_index=0,target_begin=0,target_len=28672,target_name=linear,target_version=1.4.0,
 485  device_name=253:1,start=2048;
 486
 487 5. mirror
 488 ----------
 489 The 'target_attributes' (described as part of EVENT_DATA in 'Table load'
 490 section above) has the following data format for 'mirror' target.
 491
 492 ::
 493
 494  target_attributes := <target_name> "," <target_version> "," <nr_mirrors> ","
 495                       <mirror_device_data> "," <handle_errors> "," <keep_log> "," <log_type_status> ";"
 496
 497  target_name := "target_name=mirror"
 498  target_version := "target_version=" <N> "." <N> "." <N>
 499  nr_mirrors := "nr_mirrors=" <NR>
 500  mirror_device_data := <mirror_device_row> | <mirror_device_data><mirror_device_row>
 501                        mirror_device_row is repeated <NR> times - for <NR> described in <nr_mirrors>.
 502  mirror_device_row := <mirror_device_name> "," <mirror_device_status>
 503  mirror_device_name := "mirror_device_" <X> "=" <mirror_device_name_str>
 504                        where <X> ranges from 0 to (<NR> -1) - for <NR> described in <nr_mirrors>.
 505  mirror_device_status := "mirror_device_" <X> "_status=" <mirror_device_status_char>
 506                          where <X> ranges from 0 to (<NR> -1) - for <NR> described in <nr_mirrors>.
 507  mirror_device_status_char := "A" | "F" | "D" | "S" | "R" | "U"
 508  handle_errors := "handle_errors=" <yes_no>
 509  keep_log := "keep_log=" <yes_no>
 510  log_type_status := "log_type_status=" <log_type_status_str>
 511  yes_no := "y" | "n"
 512
 513  E.g.
 514  When a 'mirror' target is loaded, then IMA ASCII measurement log will have an entry
 515  similar to the following, depicting what 'mirror' attributes are measured in EVENT_DATA
 516  for 'dm_table_load' event.
 517  (converted from ASCII to text for readability)
 518
 519  dm_version=4.45.0;
 520  name=mirror1,uuid=mirror_uuid1,major=253,minor=6,minor_count=1,num_targets=1;
 521  target_index=0,target_begin=0,target_len=2048,target_name=mirror,target_version=1.14.0,nr_mirrors=2,
 522     mirror_device_0=253:4,mirror_device_0_status=A,
 523     mirror_device_1=253:5,mirror_device_1_status=A,
 524  handle_errors=y,keep_log=n,log_type_status=;
 525
 526 6. multipath
 527 -------------
 528 The 'target_attributes' (described as part of EVENT_DATA in 'Table load'
 529 section above) has the following data format for 'multipath' target.
 530
 531 ::
 532
 533  target_attributes := <target_name> "," <target_version> "," <nr_priority_groups>
 534                       ["," <pg_state> "," <priority_groups> "," <priority_group_paths>] ";"
 535
 536  target_name := "target_name=multipath"
 537  target_version := "target_version=" <N> "." <N> "." <N>
 538  nr_priority_groups := "nr_priority_groups=" <NPG>
 539  priority_groups := <priority_groups_row>|<priority_groups_row><priority_groups>
 540  priority_groups_row := "pg_state_" <X> "=" <pg_state_str> "," "nr_pgpaths_" <X>  "=" <NPGP> ","
 541                         "path_selector_name_" <X> "=" <string> "," <priority_group_paths>
 542                         where <X> ranges from 0 to (<NPG> -1) - for <NPG> described in <nr_priority_groups>.
 543  pg_state_str := "E" | "A" | "D"
 544  <priority_group_paths> := <priority_group_paths_row> | <priority_group_paths_row><priority_group_paths>
 545  priority_group_paths_row := "path_name_" <X> "_" <Y> "=" <string> "," "is_active_" <X> "_" <Y> "=" <is_active_str>
 546                              "fail_count_" <X> "_" <Y> "=" <N> "," "path_selector_status_" <X> "_" <Y> "=" <path_selector_status_str>
 547                              where <X> ranges from 0 to (<NPG> -1) - for <NPG> described in <nr_priority_groups>,
 548                              and <Y> ranges from 0 to (<NPGP> -1) - for <NPGP> described in <priority_groups_row>.
 549  is_active_str := "A" | "F"
 550
 551  E.g.
 552  When a 'multipath' target is loaded, then IMA ASCII measurement log will have an entry
 553  similar to the following, depicting what 'multipath' attributes are measured in EVENT_DATA
 554  for 'dm_table_load' event.
 555  (converted from ASCII to text for readability)
 556
 557  dm_version=4.45.0;
 558  name=mp,uuid=,major=253,minor=0,minor_count=1,num_targets=1;
 559  target_index=0,target_begin=0,target_len=2097152,target_name=multipath,target_version=1.14.0,nr_priority_groups=2,
 560     pg_state_0=E,nr_pgpaths_0=2,path_selector_name_0=queue-length,
 561         path_name_0_0=8:16,is_active_0_0=A,fail_count_0_0=0,path_selector_status_0_0=,
 562         path_name_0_1=8:32,is_active_0_1=A,fail_count_0_1=0,path_selector_status_0_1=,
 563     pg_state_1=E,nr_pgpaths_1=2,path_selector_name_1=queue-length,
 564         path_name_1_0=8:48,is_active_1_0=A,fail_count_1_0=0,path_selector_status_1_0=,
 565         path_name_1_1=8:64,is_active_1_1=A,fail_count_1_1=0,path_selector_status_1_1=;
 566
 567 7. raid
 568 --------
 569 The 'target_attributes' (described as part of EVENT_DATA in 'Table load'
 570 section above) has the following data format for 'raid' target.
 571
 572 ::
 573
 574  target_attributes := <target_name> "," <target_version> "," <raid_type> "," <raid_disks> "," <raid_state>
 575                       <raid_device_status> ["," journal_dev_mode] ";"
 576
 577  target_name := "target_name=raid"
 578  target_version := "target_version=" <N> "." <N> "." <N>
 579  raid_type := "raid_type=" <raid_type_str>
 580  raid_disks := "raid_disks=" <NRD>
 581  raid_state := "raid_state=" <raid_state_str>
 582  raid_state_str := "frozen" | "reshape" |"resync" | "check" | "repair" | "recover" | "idle" |"undef"
 583  raid_device_status := <raid_device_status_row> | <raid_device_status_row><raid_device_status>
 584                        <raid_device_status_row> is repeated <NRD> times - for <NRD> described in <raid_disks>.
 585  raid_device_status_row := "raid_device_" <X> "_status=" <raid_device_status_str>
 586                            where <X> ranges from 0 to (<NRD> -1) - for <NRD> described in <raid_disks>.
 587  raid_device_status_str := "A" | "D" | "a" | "-"
 588  journal_dev_mode := "journal_dev_mode=" <journal_dev_mode_str>
 589  journal_dev_mode_str := "writethrough" | "writeback" | "invalid"
 590
 591  E.g.
 592  When a 'raid' target is loaded, then IMA ASCII measurement log will have an entry
 593  similar to the following, depicting what 'raid' attributes are measured in EVENT_DATA
 594  for 'dm_table_load' event.
 595  (converted from ASCII to text for readability)
 596
 597  dm_version=4.45.0;
 598  name=raid_LV1,uuid=uuid_raid_LV1,major=253,minor=12,minor_count=1,num_targets=1;
 599  target_index=0,target_begin=0,target_len=2048,target_name=raid,target_version=1.15.1,
 600  raid_type=raid10,raid_disks=4,raid_state=idle,
 601     raid_device_0_status=A,
 602     raid_device_1_status=A,
 603     raid_device_2_status=A,
 604     raid_device_3_status=A;
 605
 606
 607 8. snapshot
 608 ------------
 609 The 'target_attributes' (described as part of EVENT_DATA in 'Table load'
 610 section above) has the following data format for 'snapshot' target.
 611
 612 ::
 613
 614  target_attributes := <target_name> "," <target_version> "," <snap_origin_name> ","
 615                       <snap_cow_name> "," <snap_valid> "," <snap_merge_failed> "," <snapshot_overflowed> ";"
 616
 617  target_name := "target_name=snapshot"
 618  target_version := "target_version=" <N> "." <N> "." <N>
 619  snap_origin_name := "snap_origin_name=" <string>
 620  snap_cow_name := "snap_cow_name=" <string>
 621  snap_valid := "snap_valid=" <yes_no>
 622  snap_merge_failed := "snap_merge_failed=" <yes_no>
 623  snapshot_overflowed := "snapshot_overflowed=" <yes_no>
 624  yes_no := "y" | "n"
 625
 626  E.g.
 627  When a 'snapshot' target is loaded, then IMA ASCII measurement log will have an entry
 628  similar to the following, depicting what 'snapshot' attributes are measured in EVENT_DATA
 629  for 'dm_table_load' event.
 630  (converted from ASCII to text for readability)
 631
 632  dm_version=4.45.0;
 633  name=snap1,uuid=snap_uuid1,major=253,minor=13,minor_count=1,num_targets=1;
 634  target_index=0,target_begin=0,target_len=4096,target_name=snapshot,target_version=1.16.0,
 635  snap_origin_name=253:11,snap_cow_name=253:12,snap_valid=y,snap_merge_failed=n,snapshot_overflowed=n;
 636
 637 9. striped
 638 -----------
 639 The 'target_attributes' (described as part of EVENT_DATA in 'Table load'
 640 section above) has the following data format for 'striped' target.
 641
 642 ::
 643
 644  target_attributes := <target_name> "," <target_version> "," <stripes> "," <chunk_size> ","
 645                       <stripe_data> ";"
 646
 647  target_name := "target_name=striped"
 648  target_version := "target_version=" <N> "." <N> "." <N>
 649  stripes := "stripes=" <NS>
 650  chunk_size := "chunk_size=" <N>
 651  stripe_data := <stripe_data_row>|<stripe_data><stripe_data_row>
 652  stripe_data_row := <stripe_device_name> "," <stripe_physical_start> "," <stripe_status>
 653  stripe_device_name := "stripe_" <X> "_device_name=" <stripe_device_name_str>
 654                        where <X> ranges from 0 to (<NS> -1) - for <NS> described in <stripes>.
 655  stripe_physical_start := "stripe_" <X> "_physical_start=" <N>
 656                            where <X> ranges from 0 to (<NS> -1) - for <NS> described in <stripes>.
 657  stripe_status := "stripe_" <X> "_status=" <stripe_status_str>
 658                   where <X> ranges from 0 to (<NS> -1) - for <NS> described in <stripes>.
 659  stripe_status_str := "D" | "A"
 660
 661  E.g.
 662  When a 'striped' target is loaded, then IMA ASCII measurement log will have an entry
 663  similar to the following, depicting what 'striped' attributes are measured in EVENT_DATA
 664  for 'dm_table_load' event.
 665  (converted from ASCII to text for readability)
 666
 667  dm_version=4.45.0;
 668  name=striped1,uuid=striped_uuid1,major=253,minor=5,minor_count=1,num_targets=1;
 669  target_index=0,target_begin=0,target_len=640,target_name=striped,target_version=1.6.0,stripes=2,chunk_size=64,
 670     stripe_0_device_name=253:0,stripe_0_physical_start=2048,stripe_0_status=A,
 671     stripe_1_device_name=253:3,stripe_1_physical_start=2048,stripe_1_status=A;
 672
 673 10. verity
 674 ----------
 675 The 'target_attributes' (described as part of EVENT_DATA in 'Table load'
 676 section above) has the following data format for 'verity' target.
 677
 678 ::
 679
 680  target_attributes := <target_name> "," <target_version> "," <hash_failed> "," <verity_version> ","
 681                       <data_device_name> "," <hash_device_name> "," <verity_algorithm> "," <root_digest> ","
 682                       <salt> "," <ignore_zero_blocks> "," <check_at_most_once> ["," <root_hash_sig_key_desc>]
 683                       ["," <verity_mode>] ";"
 684
 685  target_name := "target_name=verity"
 686  target_version := "target_version=" <N> "." <N> "." <N>
 687  hash_failed := "hash_failed=" <hash_failed_str>
 688  hash_failed_str := "C" | "V"
 689  verity_version := "verity_version=" <verity_version_str>
 690  data_device_name := "data_device_name=" <data_device_name_str>
 691  hash_device_name := "hash_device_name=" <hash_device_name_str>
 692  verity_algorithm := "verity_algorithm=" <verity_algorithm_str>
 693  root_digest := "root_digest=" <root_digest_str>
 694  salt := "salt=" <salt_str>
 695  salt_str := "-" <verity_salt_str>
 696  ignore_zero_blocks := "ignore_zero_blocks=" <yes_no>
 697  check_at_most_once := "check_at_most_once=" <yes_no>
 698  root_hash_sig_key_desc := "root_hash_sig_key_desc="
 699  verity_mode := "verity_mode=" <verity_mode_str>
 700  verity_mode_str := "ignore_corruption" | "restart_on_corruption" | "panic_on_corruption" | "invalid"
 701  yes_no := "y" | "n"
 702
 703  E.g.
 704  When a 'verity' target is loaded, then IMA ASCII measurement log will have an entry
 705  similar to the following, depicting what 'verity' attributes are measured in EVENT_DATA
 706  for 'dm_table_load' event.
 707  (converted from ASCII to text for readability)
 708
 709  dm_version=4.45.0;
 710  name=test-verity,uuid=,major=253,minor=2,minor_count=1,num_targets=1;
 711  target_index=0,target_begin=0,target_len=1953120,target_name=verity,target_version=1.8.0,hash_failed=V,
 712  verity_version=1,data_device_name=253:1,hash_device_name=253:0,verity_algorithm=sha256,
 713  root_digest=29cb87e60ce7b12b443ba6008266f3e41e93e403d7f298f8e3f316b29ff89c5e,
 714  salt=e48da609055204e89ae53b655ca2216dd983cf3cb829f34f63a297d106d53e2d,
 715  ignore_zero_blocks=n,check_at_most_once=n;