716 lines
32 KiB
ReStructuredText
716 lines
32 KiB
ReStructuredText
======
|
||
dm-ima
|
||
======
|
||
|
||
For a given system, various external services/infrastructure tools
|
||
(including the attestation service) interact with it - both during the
|
||
setup and during rest of the system run-time. They share sensitive data
|
||
and/or execute critical workload on that system. The external services
|
||
may want to verify the current run-time state of the relevant kernel
|
||
subsystems before fully trusting the system with business-critical
|
||
data/workload.
|
||
|
||
Device mapper plays a critical role on a given system by providing
|
||
various important functionalities to the block devices using various
|
||
target types like crypt, verity, integrity etc. Each of these target
|
||
types’ functionalities can be configured with various attributes.
|
||
The attributes chosen to configure these target types can significantly
|
||
impact the security profile of the block device, and in-turn, of the
|
||
system itself. For instance, the type of encryption algorithm and the
|
||
key size determines the strength of encryption for a given block device.
|
||
|
||
Therefore, verifying the current state of various block devices as well
|
||
as their various target attributes is crucial for external services before
|
||
fully trusting the system with business-critical data/workload.
|
||
|
||
IMA kernel subsystem provides the necessary functionality for
|
||
device mapper to measure the state and configuration of
|
||
various block devices -
|
||
|
||
- by device mapper itself, from within the kernel,
|
||
- in a tamper resistant way,
|
||
- and re-measured - triggered on state/configuration change.
|
||
|
||
Setting the IMA Policy:
|
||
=======================
|
||
For IMA to measure the data on a given system, the IMA policy on the
|
||
system needs to be updated to have following line, and the system needs
|
||
to be restarted for the measurements to take effect.
|
||
|
||
::
|
||
|
||
/etc/ima/ima-policy
|
||
measure func=CRITICAL_DATA label=device-mapper template=ima-buf
|
||
|
||
The measurements will be reflected in the IMA logs, which are located at:
|
||
|
||
::
|
||
|
||
/sys/kernel/security/integrity/ima/ascii_runtime_measurements
|
||
/sys/kernel/security/integrity/ima/binary_runtime_measurements
|
||
|
||
Then IMA ASCII measurement log has the following format:
|
||
|
||
::
|
||
|
||
<PCR> <TEMPLATE_DATA_DIGEST> <TEMPLATE_NAME> <TEMPLATE_DATA>
|
||
|
||
PCR := Platform Configuration Register, in which the values are registered.
|
||
This is applicable if TPM chip is in use.
|
||
|
||
TEMPLATE_DATA_DIGEST := Template data digest of the IMA record.
|
||
TEMPLATE_NAME := Template name that registered the integrity value (e.g. ima-buf).
|
||
|
||
TEMPLATE_DATA := <ALG> ":" <EVENT_DIGEST> <EVENT_NAME> <EVENT_DATA>
|
||
It contains data for the specific event to be measured,
|
||
in a given template data format.
|
||
|
||
ALG := Algorithm to compute event digest
|
||
EVENT_DIGEST := Digest of the event data
|
||
EVENT_NAME := Description of the event (e.g. 'dm_table_load').
|
||
EVENT_DATA := The event data to be measured.
|
||
|
||
|
|
||
|
||
| *NOTE #1:*
|
||
| The DM target data measured by IMA subsystem can alternatively
|
||
be queried from userspace by setting DM_IMA_MEASUREMENT_FLAG with
|
||
DM_TABLE_STATUS_CMD.
|
||
|
||
|
|
||
|
||
| *NOTE #2:*
|
||
| The Kernel configuration CONFIG_IMA_DISABLE_HTABLE allows measurement of duplicate records.
|
||
| To support recording duplicate IMA events in the IMA log, the Kernel needs to be configured with
|
||
CONFIG_IMA_DISABLE_HTABLE=y.
|
||
|
||
Supported Device States:
|
||
========================
|
||
Following device state changes will trigger IMA measurements:
|
||
|
||
1. Table load
|
||
#. Device resume
|
||
#. Device remove
|
||
#. Table clear
|
||
#. Device rename
|
||
|
||
1. Table load:
|
||
---------------
|
||
When a new table is loaded in a device's inactive table slot,
|
||
the device information and target specific details from the
|
||
targets in the table are measured.
|
||
|
||
The IMA measurement log has the following format for 'dm_table_load':
|
||
|
||
::
|
||
|
||
EVENT_NAME := "dm_table_load"
|
||
EVENT_DATA := <dm_version_str> ";" <device_metadata> ";" <table_load_data>
|
||
|
||
dm_version_str := "dm_version=" <N> "." <N> "." <N>
|
||
Same as Device Mapper driver version.
|
||
device_metadata := <device_name> "," <device_uuid> "," <device_major> "," <device_minor> ","
|
||
<minor_count> "," <num_device_targets> ";"
|
||
|
||
device_name := "name=" <dm-device-name>
|
||
device_uuid := "uuid=" <dm-device-uuid>
|
||
device_major := "major=" <N>
|
||
device_minor := "minor=" <N>
|
||
minor_count := "minor_count=" <N>
|
||
num_device_targets := "num_targets=" <N>
|
||
dm-device-name := Name of the device. If it contains special characters like '\', ',', ';',
|
||
they are prefixed with '\'.
|
||
dm-device-uuid := UUID of the device. If it contains special characters like '\', ',', ';',
|
||
they are prefixed with '\'.
|
||
|
||
table_load_data := <target_data>
|
||
Represents the data (as name=value pairs) from various targets in the table,
|
||
which is being loaded into the DM device's inactive table slot.
|
||
target_data := <target_data_row> | <target_data><target_data_row>
|
||
|
||
target_data_row := <target_index> "," <target_begin> "," <target_len> "," <target_name> ","
|
||
<target_version> "," <target_attributes> ";"
|
||
target_index := "target_index=" <N>
|
||
Represents nth target in the table (from 0 to N-1 targets specified in <num_device_targets>)
|
||
If all the data for N targets doesn't fit in the given buffer - then the data that fits
|
||
in the buffer (say from target 0 to x) is measured in a given IMA event.
|
||
The remaining data from targets x+1 to N-1 is measured in the subsequent IMA events,
|
||
with the same format as that of 'dm_table_load'
|
||
i.e. <dm_version_str> ";" <device_metadata> ";" <table_load_data>.
|
||
|
||
target_begin := "target_begin=" <N>
|
||
target_len := "target_len=" <N>
|
||
target_name := Name of the target. 'linear', 'crypt', 'integrity' etc.
|
||
The targets that are supported for IMA measurements are documented below in the
|
||
'Supported targets' section.
|
||
target_version := "target_version=" <N> "." <N> "." <N>
|
||
target_attributes := Data containing comma separated list of name=value pairs of target specific attributes.
|
||
|
||
For instance, if a linear device is created with the following table entries,
|
||
# dmsetup create linear1
|
||
0 2 linear /dev/loop0 512
|
||
2 2 linear /dev/loop0 512
|
||
4 2 linear /dev/loop0 512
|
||
6 2 linear /dev/loop0 512
|
||
|
||
Then IMA ASCII measurement log will have the following entry:
|
||
(converted from ASCII to text for readability)
|
||
|
||
10 a8c5ff755561c7a28146389d1514c318592af49a ima-buf sha256:4d73481ecce5eadba8ab084640d85bb9ca899af4d0a122989252a76efadc5b72
|
||
dm_table_load
|
||
dm_version=4.45.0;
|
||
name=linear1,uuid=,major=253,minor=0,minor_count=1,num_targets=4;
|
||
target_index=0,target_begin=0,target_len=2,target_name=linear,target_version=1.4.0,device_name=7:0,start=512;
|
||
target_index=1,target_begin=2,target_len=2,target_name=linear,target_version=1.4.0,device_name=7:0,start=512;
|
||
target_index=2,target_begin=4,target_len=2,target_name=linear,target_version=1.4.0,device_name=7:0,start=512;
|
||
target_index=3,target_begin=6,target_len=2,target_name=linear,target_version=1.4.0,device_name=7:0,start=512;
|
||
|
||
2. Device resume:
|
||
------------------
|
||
When a suspended device is resumed, the device information and the hash of the
|
||
data from previous load of an active table are measured.
|
||
|
||
The IMA measurement log has the following format for 'dm_device_resume':
|
||
|
||
::
|
||
|
||
EVENT_NAME := "dm_device_resume"
|
||
EVENT_DATA := <dm_version_str> ";" <device_metadata> ";" <active_table_hash> ";" <current_device_capacity> ";"
|
||
|
||
dm_version_str := As described in the 'Table load' section above.
|
||
device_metadata := As described in the 'Table load' section above.
|
||
active_table_hash := "active_table_hash=" <table_hash_alg> ":" <table_hash>
|
||
Rerpresents the hash of the IMA data being measured for the
|
||
active table for the device.
|
||
table_hash_alg := Algorithm used to compute the hash.
|
||
table_hash := Hash of the (<dm_version_str> ";" <device_metadata> ";" <table_load_data> ";")
|
||
as described in the 'dm_table_load' above.
|
||
Note: If the table_load data spans across multiple IMA 'dm_table_load'
|
||
events for a given device, the hash is computed combining all the event data
|
||
i.e. (<dm_version_str> ";" <device_metadata> ";" <table_load_data> ";")
|
||
across all those events.
|
||
current_device_capacity := "current_device_capacity=" <N>
|
||
|
||
For instance, if a linear device is resumed with the following command,
|
||
#dmsetup resume linear1
|
||
|
||
then IMA ASCII measurement log will have an entry with:
|
||
(converted from ASCII to text for readability)
|
||
|
||
10 56c00cc062ffc24ccd9ac2d67d194af3282b934e ima-buf sha256:e7d12c03b958b4e0e53e7363a06376be88d98a1ac191fdbd3baf5e4b77f329b6
|
||
dm_device_resume
|
||
dm_version=4.45.0;
|
||
name=linear1,uuid=,major=253,minor=0,minor_count=1,num_targets=4;
|
||
active_table_hash=sha256:4d73481ecce5eadba8ab084640d85bb9ca899af4d0a122989252a76efadc5b72;current_device_capacity=8;
|
||
|
||
3. Device remove:
|
||
------------------
|
||
When a device is removed, the device information and a sha256 hash of the
|
||
data from an active and inactive table are measured.
|
||
|
||
The IMA measurement log has the following format for 'dm_device_remove':
|
||
|
||
::
|
||
|
||
EVENT_NAME := "dm_device_remove"
|
||
EVENT_DATA := <dm_version_str> ";" <device_active_metadata> ";" <device_inactive_metadata> ";"
|
||
<active_table_hash> "," <inactive_table_hash> "," <remove_all> ";" <current_device_capacity> ";"
|
||
|
||
dm_version_str := As described in the 'Table load' section above.
|
||
device_active_metadata := Device metadata that reflects the currently loaded active table.
|
||
The format is same as 'device_metadata' described in the 'Table load' section above.
|
||
device_inactive_metadata := Device metadata that reflects the inactive table.
|
||
The format is same as 'device_metadata' described in the 'Table load' section above.
|
||
active_table_hash := Hash of the currently loaded active table.
|
||
The format is same as 'active_table_hash' described in the 'Device resume' section above.
|
||
inactive_table_hash := Hash of the inactive table.
|
||
The format is same as 'active_table_hash' described in the 'Device resume' section above.
|
||
remove_all := "remove_all=" <yes_no>
|
||
yes_no := "y" | "n"
|
||
current_device_capacity := "current_device_capacity=" <N>
|
||
|
||
For instance, if a linear device is removed with the following command,
|
||
#dmsetup remove l1
|
||
|
||
then IMA ASCII measurement log will have the following entry:
|
||
(converted from ASCII to text for readability)
|
||
|
||
10 790e830a3a7a31590824ac0642b3b31c2d0e8b38 ima-buf sha256:ab9f3c959367a8f5d4403d6ce9c3627dadfa8f9f0e7ec7899299782388de3840
|
||
dm_device_remove
|
||
dm_version=4.45.0;
|
||
device_active_metadata=name=l1,uuid=,major=253,minor=2,minor_count=1,num_targets=2;
|
||
device_inactive_metadata=name=l1,uuid=,major=253,minor=2,minor_count=1,num_targets=1;
|
||
active_table_hash=sha256:4a7e62efaebfc86af755831998b7db6f59b60d23c9534fb16a4455907957953a,
|
||
inactive_table_hash=sha256:9d79c175bc2302d55a183e8f50ad4bafd60f7692fd6249e5fd213e2464384b86,remove_all=n;
|
||
current_device_capacity=2048;
|
||
|
||
4. Table clear:
|
||
----------------
|
||
When an inactive table is cleared from the device, the device information and a sha256 hash of the
|
||
data from an inactive table are measured.
|
||
|
||
The IMA measurement log has the following format for 'dm_table_clear':
|
||
|
||
::
|
||
|
||
EVENT_NAME := "dm_table_clear"
|
||
EVENT_DATA := <dm_version_str> ";" <device_inactive_metadata> ";" <inactive_table_hash> ";" <current_device_capacity> ";"
|
||
|
||
dm_version_str := As described in the 'Table load' section above.
|
||
device_inactive_metadata := Device metadata that was captured during the load time inactive table being cleared.
|
||
The format is same as 'device_metadata' described in the 'Table load' section above.
|
||
inactive_table_hash := Hash of the inactive table being cleared from the device.
|
||
The format is same as 'active_table_hash' described in the 'Device resume' section above.
|
||
current_device_capacity := "current_device_capacity=" <N>
|
||
|
||
For instance, if a linear device's inactive table is cleared,
|
||
#dmsetup clear l1
|
||
|
||
then IMA ASCII measurement log will have an entry with:
|
||
(converted from ASCII to text for readability)
|
||
|
||
10 77d347408f557f68f0041acb0072946bb2367fe5 ima-buf sha256:42f9ca22163fdfa548e6229dece2959bc5ce295c681644240035827ada0e1db5
|
||
dm_table_clear
|
||
dm_version=4.45.0;
|
||
name=l1,uuid=,major=253,minor=2,minor_count=1,num_targets=1;
|
||
inactive_table_hash=sha256:75c0dc347063bf474d28a9907037eba060bfe39d8847fc0646d75e149045d545;current_device_capacity=1024;
|
||
|
||
5. Device rename:
|
||
------------------
|
||
When an device's NAME or UUID is changed, the device information and the new NAME and UUID
|
||
are measured.
|
||
|
||
The IMA measurement log has the following format for 'dm_device_rename':
|
||
|
||
::
|
||
|
||
EVENT_NAME := "dm_device_rename"
|
||
EVENT_DATA := <dm_version_str> ";" <device_active_metadata> ";" <new_device_name> "," <new_device_uuid> ";" <current_device_capacity> ";"
|
||
|
||
dm_version_str := As described in the 'Table load' section above.
|
||
device_active_metadata := Device metadata that reflects the currently loaded active table.
|
||
The format is same as 'device_metadata' described in the 'Table load' section above.
|
||
new_device_name := "new_name=" <dm-device-name>
|
||
dm-device-name := Same as <dm-device-name> described in 'Table load' section above
|
||
new_device_uuid := "new_uuid=" <dm-device-uuid>
|
||
dm-device-uuid := Same as <dm-device-uuid> described in 'Table load' section above
|
||
current_device_capacity := "current_device_capacity=" <N>
|
||
|
||
E.g 1: if a linear device's name is changed with the following command,
|
||
#dmsetup rename linear1 --setuuid 1234-5678
|
||
|
||
then IMA ASCII measurement log will have an entry with:
|
||
(converted from ASCII to text for readability)
|
||
|
||
10 8b0423209b4c66ac1523f4c9848c9b51ee332f48 ima-buf sha256:6847b7258134189531db593e9230b257c84f04038b5a18fd2e1473860e0569ac
|
||
dm_device_rename
|
||
dm_version=4.45.0;
|
||
name=linear1,uuid=,major=253,minor=2,minor_count=1,num_targets=1;new_name=linear1,new_uuid=1234-5678;
|
||
current_device_capacity=1024;
|
||
|
||
E.g 2: if a linear device's name is changed with the following command,
|
||
# dmsetup rename linear1 linear=2
|
||
|
||
then IMA ASCII measurement log will have an entry with:
|
||
(converted from ASCII to text for readability)
|
||
|
||
10 bef70476b99c2bdf7136fae033aa8627da1bf76f ima-buf sha256:8c6f9f53b9ef9dc8f92a2f2cca8910e622543d0f0d37d484870cb16b95111402
|
||
dm_device_rename
|
||
dm_version=4.45.0;
|
||
name=linear1,uuid=1234-5678,major=253,minor=2,minor_count=1,num_targets=1;
|
||
new_name=linear\=2,new_uuid=1234-5678;
|
||
current_device_capacity=1024;
|
||
|
||
Supported targets:
|
||
==================
|
||
|
||
Following targets are supported to measure their data using IMA:
|
||
|
||
1. cache
|
||
#. crypt
|
||
#. integrity
|
||
#. linear
|
||
#. mirror
|
||
#. multipath
|
||
#. raid
|
||
#. snapshot
|
||
#. striped
|
||
#. verity
|
||
|
||
1. cache
|
||
---------
|
||
The 'target_attributes' (described as part of EVENT_DATA in 'Table load'
|
||
section above) has the following data format for 'cache' target.
|
||
|
||
::
|
||
|
||
target_attributes := <target_name> "," <target_version> "," <metadata_mode> "," <cache_metadata_device> ","
|
||
<cache_device> "," <cache_origin_device> "," <writethrough> "," <writeback> ","
|
||
<passthrough> "," <no_discard_passdown> ";"
|
||
|
||
target_name := "target_name=cache"
|
||
target_version := "target_version=" <N> "." <N> "." <N>
|
||
metadata_mode := "metadata_mode=" <cache_metadata_mode>
|
||
cache_metadata_mode := "fail" | "ro" | "rw"
|
||
cache_device := "cache_device=" <cache_device_name_string>
|
||
cache_origin_device := "cache_origin_device=" <cache_origin_device_string>
|
||
writethrough := "writethrough=" <yes_no>
|
||
writeback := "writeback=" <yes_no>
|
||
passthrough := "passthrough=" <yes_no>
|
||
no_discard_passdown := "no_discard_passdown=" <yes_no>
|
||
yes_no := "y" | "n"
|
||
|
||
E.g.
|
||
When a 'cache' target is loaded, then IMA ASCII measurement log will have an entry
|
||
similar to the following, depicting what 'cache' attributes are measured in EVENT_DATA
|
||
for 'dm_table_load' event.
|
||
(converted from ASCII to text for readability)
|
||
|
||
dm_version=4.45.0;name=cache1,uuid=cache_uuid,major=253,minor=2,minor_count=1,num_targets=1;
|
||
target_index=0,target_begin=0,target_len=28672,target_name=cache,target_version=2.2.0,metadata_mode=rw,
|
||
cache_metadata_device=253:4,cache_device=253:3,cache_origin_device=253:5,writethrough=y,writeback=n,
|
||
passthrough=n,metadata2=y,no_discard_passdown=n;
|
||
|
||
|
||
2. crypt
|
||
---------
|
||
The 'target_attributes' (described as part of EVENT_DATA in 'Table load'
|
||
section above) has the following data format for 'crypt' target.
|
||
|
||
::
|
||
|
||
target_attributes := <target_name> "," <target_version> "," <allow_discards> "," <same_cpu_crypt> ","
|
||
<submit_from_crypt_cpus> "," <no_read_workqueue> "," <no_write_workqueue> ","
|
||
<iv_large_sectors> "," <iv_large_sectors> "," [<integrity_tag_size> ","] [<cipher_auth> ","]
|
||
[<sector_size> ","] [<cipher_string> ","] <key_size> "," <key_parts> ","
|
||
<key_extra_size> "," <key_mac_size> ";"
|
||
|
||
target_name := "target_name=crypt"
|
||
target_version := "target_version=" <N> "." <N> "." <N>
|
||
allow_discards := "allow_discards=" <yes_no>
|
||
same_cpu_crypt := "same_cpu_crypt=" <yes_no>
|
||
submit_from_crypt_cpus := "submit_from_crypt_cpus=" <yes_no>
|
||
no_read_workqueue := "no_read_workqueue=" <yes_no>
|
||
no_write_workqueue := "no_write_workqueue=" <yes_no>
|
||
iv_large_sectors := "iv_large_sectors=" <yes_no>
|
||
integrity_tag_size := "integrity_tag_size=" <N>
|
||
cipher_auth := "cipher_auth=" <string>
|
||
sector_size := "sector_size=" <N>
|
||
cipher_string := "cipher_string="
|
||
key_size := "key_size=" <N>
|
||
key_parts := "key_parts=" <N>
|
||
key_extra_size := "key_extra_size=" <N>
|
||
key_mac_size := "key_mac_size=" <N>
|
||
yes_no := "y" | "n"
|
||
|
||
E.g.
|
||
When a 'crypt' target is loaded, then IMA ASCII measurement log will have an entry
|
||
similar to the following, depicting what 'crypt' attributes are measured in EVENT_DATA
|
||
for 'dm_table_load' event.
|
||
(converted from ASCII to text for readability)
|
||
|
||
dm_version=4.45.0;
|
||
name=crypt1,uuid=crypt_uuid1,major=253,minor=0,minor_count=1,num_targets=1;
|
||
target_index=0,target_begin=0,target_len=1953125,target_name=crypt,target_version=1.23.0,
|
||
allow_discards=y,same_cpu=n,submit_from_crypt_cpus=n,no_read_workqueue=n,no_write_workqueue=n,
|
||
iv_large_sectors=n,cipher_string=aes-xts-plain64,key_size=32,key_parts=1,key_extra_size=0,key_mac_size=0;
|
||
|
||
3. integrity
|
||
-------------
|
||
The 'target_attributes' (described as part of EVENT_DATA in 'Table load'
|
||
section above) has the following data format for 'integrity' target.
|
||
|
||
::
|
||
|
||
target_attributes := <target_name> "," <target_version> "," <dev_name> "," <start>
|
||
<tag_size> "," <mode> "," [<meta_device> ","] [<block_size> ","] <recalculate> ","
|
||
<allow_discards> "," <fix_padding> "," <fix_hmac> "," <legacy_recalculate> ","
|
||
<journal_sectors> "," <interleave_sectors> "," <buffer_sectors> ";"
|
||
|
||
target_name := "target_name=integrity"
|
||
target_version := "target_version=" <N> "." <N> "." <N>
|
||
dev_name := "dev_name=" <device_name_str>
|
||
start := "start=" <N>
|
||
tag_size := "tag_size=" <N>
|
||
mode := "mode=" <integrity_mode_str>
|
||
integrity_mode_str := "J" | "B" | "D" | "R"
|
||
meta_device := "meta_device=" <meta_device_str>
|
||
block_size := "block_size=" <N>
|
||
recalculate := "recalculate=" <yes_no>
|
||
allow_discards := "allow_discards=" <yes_no>
|
||
fix_padding := "fix_padding=" <yes_no>
|
||
fix_hmac := "fix_hmac=" <yes_no>
|
||
legacy_recalculate := "legacy_recalculate=" <yes_no>
|
||
journal_sectors := "journal_sectors=" <N>
|
||
interleave_sectors := "interleave_sectors=" <N>
|
||
buffer_sectors := "buffer_sectors=" <N>
|
||
yes_no := "y" | "n"
|
||
|
||
E.g.
|
||
When a 'integrity' target is loaded, then IMA ASCII measurement log will have an entry
|
||
similar to the following, depicting what 'integrity' attributes are measured in EVENT_DATA
|
||
for 'dm_table_load' event.
|
||
(converted from ASCII to text for readability)
|
||
|
||
dm_version=4.45.0;
|
||
name=integrity1,uuid=,major=253,minor=1,minor_count=1,num_targets=1;
|
||
target_index=0,target_begin=0,target_len=7856,target_name=integrity,target_version=1.10.0,
|
||
dev_name=253:0,start=0,tag_size=32,mode=J,recalculate=n,allow_discards=n,fix_padding=n,
|
||
fix_hmac=n,legacy_recalculate=n,journal_sectors=88,interleave_sectors=32768,buffer_sectors=128;
|
||
|
||
|
||
4. linear
|
||
----------
|
||
The 'target_attributes' (described as part of EVENT_DATA in 'Table load'
|
||
section above) has the following data format for 'linear' target.
|
||
|
||
::
|
||
|
||
target_attributes := <target_name> "," <target_version> "," <device_name> <,> <start> ";"
|
||
|
||
target_name := "target_name=linear"
|
||
target_version := "target_version=" <N> "." <N> "." <N>
|
||
device_name := "device_name=" <linear_device_name_str>
|
||
start := "start=" <N>
|
||
|
||
E.g.
|
||
When a 'linear' target is loaded, then IMA ASCII measurement log will have an entry
|
||
similar to the following, depicting what 'linear' attributes are measured in EVENT_DATA
|
||
for 'dm_table_load' event.
|
||
(converted from ASCII to text for readability)
|
||
|
||
dm_version=4.45.0;
|
||
name=linear1,uuid=linear_uuid1,major=253,minor=2,minor_count=1,num_targets=1;
|
||
target_index=0,target_begin=0,target_len=28672,target_name=linear,target_version=1.4.0,
|
||
device_name=253:1,start=2048;
|
||
|
||
5. mirror
|
||
----------
|
||
The 'target_attributes' (described as part of EVENT_DATA in 'Table load'
|
||
section above) has the following data format for 'mirror' target.
|
||
|
||
::
|
||
|
||
target_attributes := <target_name> "," <target_version> "," <nr_mirrors> ","
|
||
<mirror_device_data> "," <handle_errors> "," <keep_log> "," <log_type_status> ";"
|
||
|
||
target_name := "target_name=mirror"
|
||
target_version := "target_version=" <N> "." <N> "." <N>
|
||
nr_mirrors := "nr_mirrors=" <NR>
|
||
mirror_device_data := <mirror_device_row> | <mirror_device_data><mirror_device_row>
|
||
mirror_device_row is repeated <NR> times - for <NR> described in <nr_mirrors>.
|
||
mirror_device_row := <mirror_device_name> "," <mirror_device_status>
|
||
mirror_device_name := "mirror_device_" <X> "=" <mirror_device_name_str>
|
||
where <X> ranges from 0 to (<NR> -1) - for <NR> described in <nr_mirrors>.
|
||
mirror_device_status := "mirror_device_" <X> "_status=" <mirror_device_status_char>
|
||
where <X> ranges from 0 to (<NR> -1) - for <NR> described in <nr_mirrors>.
|
||
mirror_device_status_char := "A" | "F" | "D" | "S" | "R" | "U"
|
||
handle_errors := "handle_errors=" <yes_no>
|
||
keep_log := "keep_log=" <yes_no>
|
||
log_type_status := "log_type_status=" <log_type_status_str>
|
||
yes_no := "y" | "n"
|
||
|
||
E.g.
|
||
When a 'mirror' target is loaded, then IMA ASCII measurement log will have an entry
|
||
similar to the following, depicting what 'mirror' attributes are measured in EVENT_DATA
|
||
for 'dm_table_load' event.
|
||
(converted from ASCII to text for readability)
|
||
|
||
dm_version=4.45.0;
|
||
name=mirror1,uuid=mirror_uuid1,major=253,minor=6,minor_count=1,num_targets=1;
|
||
target_index=0,target_begin=0,target_len=2048,target_name=mirror,target_version=1.14.0,nr_mirrors=2,
|
||
mirror_device_0=253:4,mirror_device_0_status=A,
|
||
mirror_device_1=253:5,mirror_device_1_status=A,
|
||
handle_errors=y,keep_log=n,log_type_status=;
|
||
|
||
6. multipath
|
||
-------------
|
||
The 'target_attributes' (described as part of EVENT_DATA in 'Table load'
|
||
section above) has the following data format for 'multipath' target.
|
||
|
||
::
|
||
|
||
target_attributes := <target_name> "," <target_version> "," <nr_priority_groups>
|
||
["," <pg_state> "," <priority_groups> "," <priority_group_paths>] ";"
|
||
|
||
target_name := "target_name=multipath"
|
||
target_version := "target_version=" <N> "." <N> "." <N>
|
||
nr_priority_groups := "nr_priority_groups=" <NPG>
|
||
priority_groups := <priority_groups_row>|<priority_groups_row><priority_groups>
|
||
priority_groups_row := "pg_state_" <X> "=" <pg_state_str> "," "nr_pgpaths_" <X> "=" <NPGP> ","
|
||
"path_selector_name_" <X> "=" <string> "," <priority_group_paths>
|
||
where <X> ranges from 0 to (<NPG> -1) - for <NPG> described in <nr_priority_groups>.
|
||
pg_state_str := "E" | "A" | "D"
|
||
<priority_group_paths> := <priority_group_paths_row> | <priority_group_paths_row><priority_group_paths>
|
||
priority_group_paths_row := "path_name_" <X> "_" <Y> "=" <string> "," "is_active_" <X> "_" <Y> "=" <is_active_str>
|
||
"fail_count_" <X> "_" <Y> "=" <N> "," "path_selector_status_" <X> "_" <Y> "=" <path_selector_status_str>
|
||
where <X> ranges from 0 to (<NPG> -1) - for <NPG> described in <nr_priority_groups>,
|
||
and <Y> ranges from 0 to (<NPGP> -1) - for <NPGP> described in <priority_groups_row>.
|
||
is_active_str := "A" | "F"
|
||
|
||
E.g.
|
||
When a 'multipath' target is loaded, then IMA ASCII measurement log will have an entry
|
||
similar to the following, depicting what 'multipath' attributes are measured in EVENT_DATA
|
||
for 'dm_table_load' event.
|
||
(converted from ASCII to text for readability)
|
||
|
||
dm_version=4.45.0;
|
||
name=mp,uuid=,major=253,minor=0,minor_count=1,num_targets=1;
|
||
target_index=0,target_begin=0,target_len=2097152,target_name=multipath,target_version=1.14.0,nr_priority_groups=2,
|
||
pg_state_0=E,nr_pgpaths_0=2,path_selector_name_0=queue-length,
|
||
path_name_0_0=8:16,is_active_0_0=A,fail_count_0_0=0,path_selector_status_0_0=,
|
||
path_name_0_1=8:32,is_active_0_1=A,fail_count_0_1=0,path_selector_status_0_1=,
|
||
pg_state_1=E,nr_pgpaths_1=2,path_selector_name_1=queue-length,
|
||
path_name_1_0=8:48,is_active_1_0=A,fail_count_1_0=0,path_selector_status_1_0=,
|
||
path_name_1_1=8:64,is_active_1_1=A,fail_count_1_1=0,path_selector_status_1_1=;
|
||
|
||
7. raid
|
||
--------
|
||
The 'target_attributes' (described as part of EVENT_DATA in 'Table load'
|
||
section above) has the following data format for 'raid' target.
|
||
|
||
::
|
||
|
||
target_attributes := <target_name> "," <target_version> "," <raid_type> "," <raid_disks> "," <raid_state>
|
||
<raid_device_status> ["," journal_dev_mode] ";"
|
||
|
||
target_name := "target_name=raid"
|
||
target_version := "target_version=" <N> "." <N> "." <N>
|
||
raid_type := "raid_type=" <raid_type_str>
|
||
raid_disks := "raid_disks=" <NRD>
|
||
raid_state := "raid_state=" <raid_state_str>
|
||
raid_state_str := "frozen" | "reshape" |"resync" | "check" | "repair" | "recover" | "idle" |"undef"
|
||
raid_device_status := <raid_device_status_row> | <raid_device_status_row><raid_device_status>
|
||
<raid_device_status_row> is repeated <NRD> times - for <NRD> described in <raid_disks>.
|
||
raid_device_status_row := "raid_device_" <X> "_status=" <raid_device_status_str>
|
||
where <X> ranges from 0 to (<NRD> -1) - for <NRD> described in <raid_disks>.
|
||
raid_device_status_str := "A" | "D" | "a" | "-"
|
||
journal_dev_mode := "journal_dev_mode=" <journal_dev_mode_str>
|
||
journal_dev_mode_str := "writethrough" | "writeback" | "invalid"
|
||
|
||
E.g.
|
||
When a 'raid' target is loaded, then IMA ASCII measurement log will have an entry
|
||
similar to the following, depicting what 'raid' attributes are measured in EVENT_DATA
|
||
for 'dm_table_load' event.
|
||
(converted from ASCII to text for readability)
|
||
|
||
dm_version=4.45.0;
|
||
name=raid_LV1,uuid=uuid_raid_LV1,major=253,minor=12,minor_count=1,num_targets=1;
|
||
target_index=0,target_begin=0,target_len=2048,target_name=raid,target_version=1.15.1,
|
||
raid_type=raid10,raid_disks=4,raid_state=idle,
|
||
raid_device_0_status=A,
|
||
raid_device_1_status=A,
|
||
raid_device_2_status=A,
|
||
raid_device_3_status=A;
|
||
|
||
|
||
8. snapshot
|
||
------------
|
||
The 'target_attributes' (described as part of EVENT_DATA in 'Table load'
|
||
section above) has the following data format for 'snapshot' target.
|
||
|
||
::
|
||
|
||
target_attributes := <target_name> "," <target_version> "," <snap_origin_name> ","
|
||
<snap_cow_name> "," <snap_valid> "," <snap_merge_failed> "," <snapshot_overflowed> ";"
|
||
|
||
target_name := "target_name=snapshot"
|
||
target_version := "target_version=" <N> "." <N> "." <N>
|
||
snap_origin_name := "snap_origin_name=" <string>
|
||
snap_cow_name := "snap_cow_name=" <string>
|
||
snap_valid := "snap_valid=" <yes_no>
|
||
snap_merge_failed := "snap_merge_failed=" <yes_no>
|
||
snapshot_overflowed := "snapshot_overflowed=" <yes_no>
|
||
yes_no := "y" | "n"
|
||
|
||
E.g.
|
||
When a 'snapshot' target is loaded, then IMA ASCII measurement log will have an entry
|
||
similar to the following, depicting what 'snapshot' attributes are measured in EVENT_DATA
|
||
for 'dm_table_load' event.
|
||
(converted from ASCII to text for readability)
|
||
|
||
dm_version=4.45.0;
|
||
name=snap1,uuid=snap_uuid1,major=253,minor=13,minor_count=1,num_targets=1;
|
||
target_index=0,target_begin=0,target_len=4096,target_name=snapshot,target_version=1.16.0,
|
||
snap_origin_name=253:11,snap_cow_name=253:12,snap_valid=y,snap_merge_failed=n,snapshot_overflowed=n;
|
||
|
||
9. striped
|
||
-----------
|
||
The 'target_attributes' (described as part of EVENT_DATA in 'Table load'
|
||
section above) has the following data format for 'striped' target.
|
||
|
||
::
|
||
|
||
target_attributes := <target_name> "," <target_version> "," <stripes> "," <chunk_size> ","
|
||
<stripe_data> ";"
|
||
|
||
target_name := "target_name=striped"
|
||
target_version := "target_version=" <N> "." <N> "." <N>
|
||
stripes := "stripes=" <NS>
|
||
chunk_size := "chunk_size=" <N>
|
||
stripe_data := <stripe_data_row>|<stripe_data><stripe_data_row>
|
||
stripe_data_row := <stripe_device_name> "," <stripe_physical_start> "," <stripe_status>
|
||
stripe_device_name := "stripe_" <X> "_device_name=" <stripe_device_name_str>
|
||
where <X> ranges from 0 to (<NS> -1) - for <NS> described in <stripes>.
|
||
stripe_physical_start := "stripe_" <X> "_physical_start=" <N>
|
||
where <X> ranges from 0 to (<NS> -1) - for <NS> described in <stripes>.
|
||
stripe_status := "stripe_" <X> "_status=" <stripe_status_str>
|
||
where <X> ranges from 0 to (<NS> -1) - for <NS> described in <stripes>.
|
||
stripe_status_str := "D" | "A"
|
||
|
||
E.g.
|
||
When a 'striped' target is loaded, then IMA ASCII measurement log will have an entry
|
||
similar to the following, depicting what 'striped' attributes are measured in EVENT_DATA
|
||
for 'dm_table_load' event.
|
||
(converted from ASCII to text for readability)
|
||
|
||
dm_version=4.45.0;
|
||
name=striped1,uuid=striped_uuid1,major=253,minor=5,minor_count=1,num_targets=1;
|
||
target_index=0,target_begin=0,target_len=640,target_name=striped,target_version=1.6.0,stripes=2,chunk_size=64,
|
||
stripe_0_device_name=253:0,stripe_0_physical_start=2048,stripe_0_status=A,
|
||
stripe_1_device_name=253:3,stripe_1_physical_start=2048,stripe_1_status=A;
|
||
|
||
10. verity
|
||
----------
|
||
The 'target_attributes' (described as part of EVENT_DATA in 'Table load'
|
||
section above) has the following data format for 'verity' target.
|
||
|
||
::
|
||
|
||
target_attributes := <target_name> "," <target_version> "," <hash_failed> "," <verity_version> ","
|
||
<data_device_name> "," <hash_device_name> "," <verity_algorithm> "," <root_digest> ","
|
||
<salt> "," <ignore_zero_blocks> "," <check_at_most_once> ["," <root_hash_sig_key_desc>]
|
||
["," <verity_mode>] ";"
|
||
|
||
target_name := "target_name=verity"
|
||
target_version := "target_version=" <N> "." <N> "." <N>
|
||
hash_failed := "hash_failed=" <hash_failed_str>
|
||
hash_failed_str := "C" | "V"
|
||
verity_version := "verity_version=" <verity_version_str>
|
||
data_device_name := "data_device_name=" <data_device_name_str>
|
||
hash_device_name := "hash_device_name=" <hash_device_name_str>
|
||
verity_algorithm := "verity_algorithm=" <verity_algorithm_str>
|
||
root_digest := "root_digest=" <root_digest_str>
|
||
salt := "salt=" <salt_str>
|
||
salt_str := "-" <verity_salt_str>
|
||
ignore_zero_blocks := "ignore_zero_blocks=" <yes_no>
|
||
check_at_most_once := "check_at_most_once=" <yes_no>
|
||
root_hash_sig_key_desc := "root_hash_sig_key_desc="
|
||
verity_mode := "verity_mode=" <verity_mode_str>
|
||
verity_mode_str := "ignore_corruption" | "restart_on_corruption" | "panic_on_corruption" | "invalid"
|
||
yes_no := "y" | "n"
|
||
|
||
E.g.
|
||
When a 'verity' target is loaded, then IMA ASCII measurement log will have an entry
|
||
similar to the following, depicting what 'verity' attributes are measured in EVENT_DATA
|
||
for 'dm_table_load' event.
|
||
(converted from ASCII to text for readability)
|
||
|
||
dm_version=4.45.0;
|
||
name=test-verity,uuid=,major=253,minor=2,minor_count=1,num_targets=1;
|
||
target_index=0,target_begin=0,target_len=1953120,target_name=verity,target_version=1.8.0,hash_failed=V,
|
||
verity_version=1,data_device_name=253:1,hash_device_name=253:0,verity_algorithm=sha256,
|
||
root_digest=29cb87e60ce7b12b443ba6008266f3e41e93e403d7f298f8e3f316b29ff89c5e,
|
||
salt=e48da609055204e89ae53b655ca2216dd983cf3cb829f34f63a297d106d53e2d,
|
||
ignore_zero_blocks=n,check_at_most_once=n;
|