1====== 2dm-ima 3====== 4 5For a given system, various external services/infrastructure tools 6(including the attestation service) interact with it - both during the 7setup and during rest of the system run-time. They share sensitive data 8and/or execute critical workload on that system. The external services 9may want to verify the current run-time state of the relevant kernel 10subsystems before fully trusting the system with business-critical 11data/workload. 12 13Device mapper plays a critical role on a given system by providing 14various important functionalities to the block devices using various 15target types like crypt, verity, integrity etc. Each of these target 16types’ functionalities can be configured with various attributes. 17The attributes chosen to configure these target types can significantly 18impact the security profile of the block device, and in-turn, of the 19system itself. For instance, the type of encryption algorithm and the 20key size determines the strength of encryption for a given block device. 21 22Therefore, verifying the current state of various block devices as well 23as their various target attributes is crucial for external services before 24fully trusting the system with business-critical data/workload. 25 26IMA kernel subsystem provides the necessary functionality for 27device mapper to measure the state and configuration of 28various 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 34Setting the IMA Policy: 35======================= 36For IMA to measure the data on a given system, the IMA policy on the 37system needs to be updated to have following line, and the system needs 38to 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 45The 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 52Then 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 87Supported Device States: 88======================== 89Following 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 971. Table load: 98--------------- 99When a new table is loaded in a device's inactive table slot, 100the device information and target specific details from the 101targets in the table are measured. 102 103The 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 1682. Device resume: 169------------------ 170When a suspended device is resumed, the device information and the hash of the 171data from previous load of an active table are measured. 172 173The 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 2063. Device remove: 207------------------ 208When a device is removed, the device information and a sha256 hash of the 209data from an active and inactive table are measured. 210 211The 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 2474. Table clear: 248---------------- 249When an inactive table is cleared from the device, the device information and a sha256 hash of the 250data from an inactive table are measured. 251 252The 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 2785. Device rename: 279------------------ 280When an device's NAME or UUID is changed, the device information and the new NAME and UUID 281are measured. 282 283The 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 324Supported targets: 325================== 326 327Following 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 3401. cache 341--------- 342The 'target_attributes' (described as part of EVENT_DATA in 'Table load' 343section 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 3752. crypt 376--------- 377The 'target_attributes' (described as part of EVENT_DATA in 'Table load' 378section 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 4183. integrity 419------------- 420The 'target_attributes' (described as part of EVENT_DATA in 'Table load' 421section 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> "," <allow_discards_keyed> "," <fix_padding> "," <fix_hmac> "," 428 <legacy_recalculate> "," 429 <journal_sectors> "," <interleave_sectors> "," <buffer_sectors> ";" 430 431 target_name := "target_name=integrity" 432 target_version := "target_version=" <N> "." <N> "." <N> 433 dev_name := "dev_name=" <device_name_str> 434 start := "start=" <N> 435 tag_size := "tag_size=" <N> 436 mode := "mode=" <integrity_mode_str> 437 integrity_mode_str := "J" | "B" | "D" | "R" 438 meta_device := "meta_device=" <meta_device_str> 439 block_size := "block_size=" <N> 440 recalculate := "recalculate=" <yes_no> 441 allow_discards := "allow_discards=" <yes_no> 442 allow_discards_keyed := "allow_discards_keyed=" <yes_no> 443 fix_padding := "fix_padding=" <yes_no> 444 fix_hmac := "fix_hmac=" <yes_no> 445 legacy_recalculate := "legacy_recalculate=" <yes_no> 446 journal_sectors := "journal_sectors=" <N> 447 interleave_sectors := "interleave_sectors=" <N> 448 buffer_sectors := "buffer_sectors=" <N> 449 yes_no := "y" | "n" 450 451 E.g. 452 When a 'integrity' target is loaded, then IMA ASCII measurement log will have an entry 453 similar to the following, depicting what 'integrity' attributes are measured in EVENT_DATA 454 for 'dm_table_load' event. 455 (converted from ASCII to text for readability) 456 457 dm_version=4.45.0; 458 name=integrity1,uuid=,major=253,minor=1,minor_count=1,num_targets=1; 459 target_index=0,target_begin=0,target_len=7856,target_name=integrity,target_version=1.10.0, 460 dev_name=253:0,start=0,tag_size=32,mode=J,recalculate=n,allow_discards=n, 461 allow_discards_keyed=n,fix_padding=n, 462 fix_hmac=n,legacy_recalculate=n,journal_sectors=88,interleave_sectors=32768,buffer_sectors=128; 463 464 4654. linear 466---------- 467The 'target_attributes' (described as part of EVENT_DATA in 'Table load' 468section above) has the following data format for 'linear' target. 469 470:: 471 472 target_attributes := <target_name> "," <target_version> "," <device_name> <,> <start> ";" 473 474 target_name := "target_name=linear" 475 target_version := "target_version=" <N> "." <N> "." <N> 476 device_name := "device_name=" <linear_device_name_str> 477 start := "start=" <N> 478 479 E.g. 480 When a 'linear' target is loaded, then IMA ASCII measurement log will have an entry 481 similar to the following, depicting what 'linear' attributes are measured in EVENT_DATA 482 for 'dm_table_load' event. 483 (converted from ASCII to text for readability) 484 485 dm_version=4.45.0; 486 name=linear1,uuid=linear_uuid1,major=253,minor=2,minor_count=1,num_targets=1; 487 target_index=0,target_begin=0,target_len=28672,target_name=linear,target_version=1.4.0, 488 device_name=253:1,start=2048; 489 4905. mirror 491---------- 492The 'target_attributes' (described as part of EVENT_DATA in 'Table load' 493section above) has the following data format for 'mirror' target. 494 495:: 496 497 target_attributes := <target_name> "," <target_version> "," <nr_mirrors> "," 498 <mirror_device_data> "," <handle_errors> "," <keep_log> "," <log_type_status> ";" 499 500 target_name := "target_name=mirror" 501 target_version := "target_version=" <N> "." <N> "." <N> 502 nr_mirrors := "nr_mirrors=" <NR> 503 mirror_device_data := <mirror_device_row> | <mirror_device_data><mirror_device_row> 504 mirror_device_row is repeated <NR> times - for <NR> described in <nr_mirrors>. 505 mirror_device_row := <mirror_device_name> "," <mirror_device_status> 506 mirror_device_name := "mirror_device_" <X> "=" <mirror_device_name_str> 507 where <X> ranges from 0 to (<NR> -1) - for <NR> described in <nr_mirrors>. 508 mirror_device_status := "mirror_device_" <X> "_status=" <mirror_device_status_char> 509 where <X> ranges from 0 to (<NR> -1) - for <NR> described in <nr_mirrors>. 510 mirror_device_status_char := "A" | "F" | "D" | "S" | "R" | "U" 511 handle_errors := "handle_errors=" <yes_no> 512 keep_log := "keep_log=" <yes_no> 513 log_type_status := "log_type_status=" <log_type_status_str> 514 yes_no := "y" | "n" 515 516 E.g. 517 When a 'mirror' target is loaded, then IMA ASCII measurement log will have an entry 518 similar to the following, depicting what 'mirror' attributes are measured in EVENT_DATA 519 for 'dm_table_load' event. 520 (converted from ASCII to text for readability) 521 522 dm_version=4.45.0; 523 name=mirror1,uuid=mirror_uuid1,major=253,minor=6,minor_count=1,num_targets=1; 524 target_index=0,target_begin=0,target_len=2048,target_name=mirror,target_version=1.14.0,nr_mirrors=2, 525 mirror_device_0=253:4,mirror_device_0_status=A, 526 mirror_device_1=253:5,mirror_device_1_status=A, 527 handle_errors=y,keep_log=n,log_type_status=; 528 5296. multipath 530------------- 531The 'target_attributes' (described as part of EVENT_DATA in 'Table load' 532section above) has the following data format for 'multipath' target. 533 534:: 535 536 target_attributes := <target_name> "," <target_version> "," <nr_priority_groups> 537 ["," <pg_state> "," <priority_groups> "," <priority_group_paths>] ";" 538 539 target_name := "target_name=multipath" 540 target_version := "target_version=" <N> "." <N> "." <N> 541 nr_priority_groups := "nr_priority_groups=" <NPG> 542 priority_groups := <priority_groups_row>|<priority_groups_row><priority_groups> 543 priority_groups_row := "pg_state_" <X> "=" <pg_state_str> "," "nr_pgpaths_" <X> "=" <NPGP> "," 544 "path_selector_name_" <X> "=" <string> "," <priority_group_paths> 545 where <X> ranges from 0 to (<NPG> -1) - for <NPG> described in <nr_priority_groups>. 546 pg_state_str := "E" | "A" | "D" 547 <priority_group_paths> := <priority_group_paths_row> | <priority_group_paths_row><priority_group_paths> 548 priority_group_paths_row := "path_name_" <X> "_" <Y> "=" <string> "," "is_active_" <X> "_" <Y> "=" <is_active_str> 549 "fail_count_" <X> "_" <Y> "=" <N> "," "path_selector_status_" <X> "_" <Y> "=" <path_selector_status_str> 550 where <X> ranges from 0 to (<NPG> -1) - for <NPG> described in <nr_priority_groups>, 551 and <Y> ranges from 0 to (<NPGP> -1) - for <NPGP> described in <priority_groups_row>. 552 is_active_str := "A" | "F" 553 554 E.g. 555 When a 'multipath' target is loaded, then IMA ASCII measurement log will have an entry 556 similar to the following, depicting what 'multipath' attributes are measured in EVENT_DATA 557 for 'dm_table_load' event. 558 (converted from ASCII to text for readability) 559 560 dm_version=4.45.0; 561 name=mp,uuid=,major=253,minor=0,minor_count=1,num_targets=1; 562 target_index=0,target_begin=0,target_len=2097152,target_name=multipath,target_version=1.14.0,nr_priority_groups=2, 563 pg_state_0=E,nr_pgpaths_0=2,path_selector_name_0=queue-length, 564 path_name_0_0=8:16,is_active_0_0=A,fail_count_0_0=0,path_selector_status_0_0=, 565 path_name_0_1=8:32,is_active_0_1=A,fail_count_0_1=0,path_selector_status_0_1=, 566 pg_state_1=E,nr_pgpaths_1=2,path_selector_name_1=queue-length, 567 path_name_1_0=8:48,is_active_1_0=A,fail_count_1_0=0,path_selector_status_1_0=, 568 path_name_1_1=8:64,is_active_1_1=A,fail_count_1_1=0,path_selector_status_1_1=; 569 5707. raid 571-------- 572The 'target_attributes' (described as part of EVENT_DATA in 'Table load' 573section above) has the following data format for 'raid' target. 574 575:: 576 577 target_attributes := <target_name> "," <target_version> "," <raid_type> "," <raid_disks> "," <raid_state> 578 <raid_device_status> ["," journal_dev_mode] ";" 579 580 target_name := "target_name=raid" 581 target_version := "target_version=" <N> "." <N> "." <N> 582 raid_type := "raid_type=" <raid_type_str> 583 raid_disks := "raid_disks=" <NRD> 584 raid_state := "raid_state=" <raid_state_str> 585 raid_state_str := "frozen" | "reshape" |"resync" | "check" | "repair" | "recover" | "idle" |"undef" 586 raid_device_status := <raid_device_status_row> | <raid_device_status_row><raid_device_status> 587 <raid_device_status_row> is repeated <NRD> times - for <NRD> described in <raid_disks>. 588 raid_device_status_row := "raid_device_" <X> "_status=" <raid_device_status_str> 589 where <X> ranges from 0 to (<NRD> -1) - for <NRD> described in <raid_disks>. 590 raid_device_status_str := "A" | "D" | "a" | "-" 591 journal_dev_mode := "journal_dev_mode=" <journal_dev_mode_str> 592 journal_dev_mode_str := "writethrough" | "writeback" | "invalid" 593 594 E.g. 595 When a 'raid' target is loaded, then IMA ASCII measurement log will have an entry 596 similar to the following, depicting what 'raid' attributes are measured in EVENT_DATA 597 for 'dm_table_load' event. 598 (converted from ASCII to text for readability) 599 600 dm_version=4.45.0; 601 name=raid_LV1,uuid=uuid_raid_LV1,major=253,minor=12,minor_count=1,num_targets=1; 602 target_index=0,target_begin=0,target_len=2048,target_name=raid,target_version=1.15.1, 603 raid_type=raid10,raid_disks=4,raid_state=idle, 604 raid_device_0_status=A, 605 raid_device_1_status=A, 606 raid_device_2_status=A, 607 raid_device_3_status=A; 608 609 6108. snapshot 611------------ 612The 'target_attributes' (described as part of EVENT_DATA in 'Table load' 613section above) has the following data format for 'snapshot' target. 614 615:: 616 617 target_attributes := <target_name> "," <target_version> "," <snap_origin_name> "," 618 <snap_cow_name> "," <snap_valid> "," <snap_merge_failed> "," <snapshot_overflowed> ";" 619 620 target_name := "target_name=snapshot" 621 target_version := "target_version=" <N> "." <N> "." <N> 622 snap_origin_name := "snap_origin_name=" <string> 623 snap_cow_name := "snap_cow_name=" <string> 624 snap_valid := "snap_valid=" <yes_no> 625 snap_merge_failed := "snap_merge_failed=" <yes_no> 626 snapshot_overflowed := "snapshot_overflowed=" <yes_no> 627 yes_no := "y" | "n" 628 629 E.g. 630 When a 'snapshot' target is loaded, then IMA ASCII measurement log will have an entry 631 similar to the following, depicting what 'snapshot' attributes are measured in EVENT_DATA 632 for 'dm_table_load' event. 633 (converted from ASCII to text for readability) 634 635 dm_version=4.45.0; 636 name=snap1,uuid=snap_uuid1,major=253,minor=13,minor_count=1,num_targets=1; 637 target_index=0,target_begin=0,target_len=4096,target_name=snapshot,target_version=1.16.0, 638 snap_origin_name=253:11,snap_cow_name=253:12,snap_valid=y,snap_merge_failed=n,snapshot_overflowed=n; 639 6409. striped 641----------- 642The 'target_attributes' (described as part of EVENT_DATA in 'Table load' 643section above) has the following data format for 'striped' target. 644 645:: 646 647 target_attributes := <target_name> "," <target_version> "," <stripes> "," <chunk_size> "," 648 <stripe_data> ";" 649 650 target_name := "target_name=striped" 651 target_version := "target_version=" <N> "." <N> "." <N> 652 stripes := "stripes=" <NS> 653 chunk_size := "chunk_size=" <N> 654 stripe_data := <stripe_data_row>|<stripe_data><stripe_data_row> 655 stripe_data_row := <stripe_device_name> "," <stripe_physical_start> "," <stripe_status> 656 stripe_device_name := "stripe_" <X> "_device_name=" <stripe_device_name_str> 657 where <X> ranges from 0 to (<NS> -1) - for <NS> described in <stripes>. 658 stripe_physical_start := "stripe_" <X> "_physical_start=" <N> 659 where <X> ranges from 0 to (<NS> -1) - for <NS> described in <stripes>. 660 stripe_status := "stripe_" <X> "_status=" <stripe_status_str> 661 where <X> ranges from 0 to (<NS> -1) - for <NS> described in <stripes>. 662 stripe_status_str := "D" | "A" 663 664 E.g. 665 When a 'striped' target is loaded, then IMA ASCII measurement log will have an entry 666 similar to the following, depicting what 'striped' attributes are measured in EVENT_DATA 667 for 'dm_table_load' event. 668 (converted from ASCII to text for readability) 669 670 dm_version=4.45.0; 671 name=striped1,uuid=striped_uuid1,major=253,minor=5,minor_count=1,num_targets=1; 672 target_index=0,target_begin=0,target_len=640,target_name=striped,target_version=1.6.0,stripes=2,chunk_size=64, 673 stripe_0_device_name=253:0,stripe_0_physical_start=2048,stripe_0_status=A, 674 stripe_1_device_name=253:3,stripe_1_physical_start=2048,stripe_1_status=A; 675 67610. verity 677---------- 678The 'target_attributes' (described as part of EVENT_DATA in 'Table load' 679section above) has the following data format for 'verity' target. 680 681:: 682 683 target_attributes := <target_name> "," <target_version> "," <hash_failed> "," <verity_version> "," 684 <data_device_name> "," <hash_device_name> "," <verity_algorithm> "," <root_digest> "," 685 <salt> "," <ignore_zero_blocks> "," <check_at_most_once> ["," <root_hash_sig_key_desc>] 686 ["," <verity_mode>] ";" 687 688 target_name := "target_name=verity" 689 target_version := "target_version=" <N> "." <N> "." <N> 690 hash_failed := "hash_failed=" <hash_failed_str> 691 hash_failed_str := "C" | "V" 692 verity_version := "verity_version=" <verity_version_str> 693 data_device_name := "data_device_name=" <data_device_name_str> 694 hash_device_name := "hash_device_name=" <hash_device_name_str> 695 verity_algorithm := "verity_algorithm=" <verity_algorithm_str> 696 root_digest := "root_digest=" <root_digest_str> 697 salt := "salt=" <salt_str> 698 salt_str := "-" <verity_salt_str> 699 ignore_zero_blocks := "ignore_zero_blocks=" <yes_no> 700 check_at_most_once := "check_at_most_once=" <yes_no> 701 root_hash_sig_key_desc := "root_hash_sig_key_desc=" 702 verity_mode := "verity_mode=" <verity_mode_str> 703 verity_mode_str := "ignore_corruption" | "restart_on_corruption" | "panic_on_corruption" | "invalid" 704 yes_no := "y" | "n" 705 706 E.g. 707 When a 'verity' target is loaded, then IMA ASCII measurement log will have an entry 708 similar to the following, depicting what 'verity' attributes are measured in EVENT_DATA 709 for 'dm_table_load' event. 710 (converted from ASCII to text for readability) 711 712 dm_version=4.45.0; 713 name=test-verity,uuid=,major=253,minor=2,minor_count=1,num_targets=1; 714 target_index=0,target_begin=0,target_len=1953120,target_name=verity,target_version=1.8.0,hash_failed=V, 715 verity_version=1,data_device_name=253:1,hash_device_name=253:0,verity_algorithm=sha256, 716 root_digest=29cb87e60ce7b12b443ba6008266f3e41e93e403d7f298f8e3f316b29ff89c5e, 717 salt=e48da609055204e89ae53b655ca2216dd983cf3cb829f34f63a297d106d53e2d, 718 ignore_zero_blocks=n,check_at_most_once=n; 719