Commit | Line | Data |
---|---|---|
00d43995 TS |
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 - | |
17bfa968 TS |
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. | |
00d43995 TS |
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 | ||
17bfa968 TS |
40 | :: |
41 | ||
42 | /etc/ima/ima-policy | |
43 | measure func=CRITICAL_DATA label=device-mapper template=ima-buf | |
00d43995 TS |
44 | |
45 | The measurements will be reflected in the IMA logs, which are located at: | |
46 | ||
17bfa968 TS |
47 | :: |
48 | ||
49 | /sys/kernel/security/integrity/ima/ascii_runtime_measurements | |
50 | /sys/kernel/security/integrity/ima/binary_runtime_measurements | |
00d43995 TS |
51 | |
52 | Then IMA ASCII measurement log has the following format: | |
00d43995 | 53 | |
17bfa968 TS |
54 | :: |
55 | ||
56 | <PCR> <TEMPLATE_DATA_DIGEST> <TEMPLATE_NAME> <TEMPLATE_DATA> | |
57 | ||
58 | PCR := Platform Configuration Register, in which the values are registered. | |
00d43995 | 59 | This is applicable if TPM chip is in use. |
00d43995 | 60 | |
17bfa968 TS |
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. | |
00d43995 TS |
86 | |
87 | Supported Device States: | |
88 | ======================== | |
17bfa968 TS |
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: | |
00d43995 TS |
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 | ||
17bfa968 TS |
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: | |
00d43995 | 169 | ------------------ |
17bfa968 | 170 | When a suspended device is resumed, the device information and the hash of the |
00d43995 TS |
171 | data from previous load of an active table are measured. |
172 | ||
17bfa968 | 173 | The IMA measurement log has the following format for 'dm_device_resume': |
00d43995 | 174 | |
17bfa968 | 175 | :: |
00d43995 | 176 | |
17bfa968 TS |
177 | EVENT_NAME := "dm_device_resume" |
178 | EVENT_DATA := <dm_version_str> ";" <device_metadata> ";" <active_table_hash> ";" <current_device_capacity> ";" | |
00d43995 | 179 | |
17bfa968 TS |
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> | |
00d43995 | 193 | |
17bfa968 TS |
194 | For instance, if a linear device is resumed with the following command, |
195 | #dmsetup resume linear1 | |
00d43995 | 196 | |
17bfa968 TS |
197 | then IMA ASCII measurement log will have an entry with: |
198 | (converted from ASCII to text for readability) | |
00d43995 | 199 | |
17bfa968 TS |
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; | |
00d43995 | 205 | |
17bfa968 TS |
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. | |
00d43995 | 210 | |
17bfa968 TS |
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: | |
00d43995 TS |
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 | ||
17bfa968 TS |
252 | The IMA measurement log has the following format for 'dm_table_clear': |
253 | ||
254 | :: | |
00d43995 | 255 | |
17bfa968 TS |
256 | EVENT_NAME := "dm_table_clear" |
257 | EVENT_DATA := <dm_version_str> ";" <device_inactive_metadata> ";" <inactive_table_hash> ";" <current_device_capacity> ";" | |
00d43995 | 258 | |
17bfa968 TS |
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> | |
00d43995 | 265 | |
17bfa968 TS |
266 | For instance, if a linear device's inactive table is cleared, |
267 | #dmsetup clear l1 | |
00d43995 | 268 | |
17bfa968 TS |
269 | then IMA ASCII measurement log will have an entry with: |
270 | (converted from ASCII to text for readability) | |
00d43995 | 271 | |
17bfa968 TS |
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: | |
00d43995 TS |
279 | ------------------ |
280 | When an device's NAME or UUID is changed, the device information and the new NAME and UUID | |
281 | are measured. | |
282 | ||
17bfa968 TS |
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 | |
00d43995 | 301 | |
17bfa968 TS |
302 | then IMA ASCII measurement log will have an entry with: |
303 | (converted from ASCII to text for readability) | |
00d43995 | 304 | |
17bfa968 TS |
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; | |
00d43995 | 310 | |
17bfa968 TS |
311 | E.g 2: if a linear device's name is changed with the following command, |
312 | # dmsetup rename linear1 linear=2 | |
00d43995 | 313 | |
17bfa968 TS |
314 | then IMA ASCII measurement log will have an entry with: |
315 | (converted from ASCII to text for readability) | |
00d43995 | 316 | |
17bfa968 TS |
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; | |
00d43995 TS |
323 | |
324 | Supported targets: | |
325 | ================== | |
00d43995 | 326 | |
17bfa968 TS |
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 | |
00d43995 | 339 | |
17bfa968 | 340 | 1. cache |
00d43995 | 341 | --------- |
17bfa968 TS |
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 | |
00d43995 | 419 | ------------- |
17bfa968 TS |
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. | |
00d43995 | 466 | |
17bfa968 | 467 | :: |
00d43995 | 468 | |
17bfa968 | 469 | target_attributes := <target_name> "," <target_version> "," <device_name> <,> <start> ";" |
00d43995 | 470 | |
17bfa968 TS |
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> | |
00d43995 | 475 | |
17bfa968 TS |
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) | |
00d43995 | 481 | |
17bfa968 TS |
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; | |
00d43995 | 486 | |
17bfa968 TS |
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 | |
00d43995 | 638 | ----------- |
17bfa968 TS |
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; | |
00d43995 TS |
672 | |
673 | 10. verity | |
674 | ---------- | |
17bfa968 TS |
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; |