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> "," <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 4624. linear 463---------- 464The 'target_attributes' (described as part of EVENT_DATA in 'Table load' 465section 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 4875. mirror 488---------- 489The 'target_attributes' (described as part of EVENT_DATA in 'Table load' 490section 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 5266. multipath 527------------- 528The 'target_attributes' (described as part of EVENT_DATA in 'Table load' 529section 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 5677. raid 568-------- 569The 'target_attributes' (described as part of EVENT_DATA in 'Table load' 570section 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 6078. snapshot 608------------ 609The 'target_attributes' (described as part of EVENT_DATA in 'Table load' 610section 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 6379. striped 638----------- 639The 'target_attributes' (described as part of EVENT_DATA in 'Table load' 640section 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 67310. verity 674---------- 675The 'target_attributes' (described as part of EVENT_DATA in 'Table load' 676section 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; 716