DM Verity for Initramfs - Timesys (2023)

Resume

On Linux-based embedded systems that implement software authentication (secure boot and chain of trust), the file system check is usually done using an initial RAM file system (initramfs). Using an initramfs is more direct and flexible, since you can more easily modify or calculate the check arguments from within the initramfs. For older kernels (< 5.4) that do not have roothash signature verification in the kernel, an initramfs is also essential if you want to run the Linux roothash signature verification during the boot sequence. However, as expected, the use of an initramfs can add unwanted boot time and storage requirements to the system. If your embedded system is running with very strict boot times or storage requirements, omitting initramfs may be beneficial to you. This can be done using a technique calledinitial device mapping.

basic principles

The Linux kernel has a driver subsystem for device mapping, where a hardware storage device can be remapped via a target driver to produce a new transparent virtual storage device. This subsystem contains some target drivers. One of them is called Verity, which is used for file system verification. Crypt is another one we commonly use that provides file system encryption. We colloquially refer to them as DM-Verity and DM-Crypt. DM-Verity is what we will be using in this post. Let's start with a simple DM-Verity example based on initramfs.

Starting with a rootfs ext4 partition, we can generate the true metadata of a build system via:

DATA_BLOCK_SIZE="4096"HASH_BLOCK_SIZE="4096"PART_SRC_EXT4=example.ext4METADATA_HASH_DEV=example.ext4.formato metadataveritysetup--Dice-block-Size=ps{DATA_BLOCK_SIZE}\--Hash-block-Size=ps{HASH_BLOCK_SIZE}ps{PART_SRC_EXT4}ps{METADATA_HASH_DEV}

The output of this command looks like:

VERITY header information e.g.ext4.metadataUUID: e17b33f3-ce02-4d9b-a0a8-90c85ebe3240hash type: 1data blocks: 16384data block size: 4096Hash block size: 4096hashing algorithm: sha256Sal: 2a4c7638f03b92bdb92d7284a742e0c4407c9ef65fdf2a7ea78ed02fde4a518broot hashish: b96a69664f9279857931dbf64f942caf909076e40fd5bd5ed8d30b53ff922941

So when we mount and pass to the root filesystem checked from initramfs at boot time, we would mount from the target device:

MAPPER_NAME="verity_example"PART_SRC_EXT4="/dev/mmcblk0p1"METADATA_HASH_DEV="/dev/mmcblk0p2"SOURCE="b96a69664f9279857931dbf64f942caf909076e40fd5bd5ed8d30b53ff922941"truth setting \--restart-on-corruption--ignore-zero-blocks\create${MAPPER_NAME}ps{PART_SRC_EXT4}ps{METADATA_HASH_DEV}ps{SOURCE}mkdir-pag/newrootmount/developer/mapper/ps{MAPPER_NAME} /newrootswitch_root/new root/sbin/Start

You're done! Each block of data contained in /newroot will now be checked by the kernel before being used. However, part of the trust chain is still missing in this example. To understand this, we need to know what the DM-Verity root hash used above is. So what is the root hash? It is basically the last top node of a special binary hash tree called a Merkle Tree. Each data block is encoded and stored at the bottom level of this binary tree. The hash pairs are then shuffled until a final hash is derived.

This Merkle Tree is also what is contained in the Verity partition or metadata file, along with some additional header information.

Therefore, before running veritysetup to create the /dev/mapper entry with verity mountable backing, the root hash must also be verified. Otherwise, someone can break your chain of trust by overwriting your entire root filesystem, metadata filesystem, and root hash entry. You can verify this root hash of your bootloader through some form of trusted/secure boot like UEFI. However, an easy way to perform signature verification is not always available in many embedded bootloaders, so we chose to do it from the kernel. Traditionally this is done within initramfs using a library like OpenSSL.

So, for example, from your build system, you can create an RSA-signed rootash via:

SOURCE="b96a69664f9279857931dbf64f942caf909076e40fd5bd5ed8d30b53ff922941"PRIVATE KEY="verity_private.pem"PUBLIC KEY="verity_public.pem"#Generate RSA key pairgenpkey the openssl-RSA algorithm-for a ${PRIVATE KEY} -pkeyopt rsa_keygen_bits:2048abre ssl rsa-Publication-they ${PRIVATE KEY} -for a ${PUBLIC KEY}#Sign the root hashecological ${SOURCE} |tr-d'\norte' >roothash.txtopenssl rsautl-plate-ink key ${PRIVATE KEY} -for a ${SOURCE}.signed-they ${SOURCE}

Then, in your embedded target, you would store the public key and signed root hash and verify authenticity via your initramfs:

# If signed correctly, return the rootash of the signed rootash fileSOURCE=$(openssl rsautl -verify -in"roothash.txt.assinado"-clave ${PUBLIC KEY}-bar)#Resultado = b96a69664f9279857931dbf64f942caf909076e40fd5bd5ed8d30b53ff922941ecological ${SOURCE}

You can then use this resulting verified rootash to run "veritysetup create" as shown above.

Linux kernel space signature check

Signature verification in the Linux kernel is done with CONFIG_DM_VERITY_VERIFY_ROOTHASH_SIG=y. This is a kernel configuration option that was added in version 5.4. Adds the ability to perform roothash signature verification in Linux kernel space without external tools or libraries.

This is used when creating an RSA certificate from the build system:

PRIVATE KEY="verity_key.pem"certificate="verity_cert.pem"requires open SSL-x509-new rsa key:1024 -clave ${PRIVATE KEY}\-for a ${certificate} -us-day365 -set_serial01 -topic in question/NORTH CAROLINA=example.com

Then you need to add the certificate to your kernel build system with the appropriate configuration options:

CONFIG_DM_VERITY_VERIFY_ROOTHASH_SIG=yCONFIG_SYSTEM_TRUSTED_KEYRING=yCONFIG_SYSTEM_TRUSTED_KEYS="verity_cert.pem"

Next, we create the build system signed root hash:

SOURCE="b96a69664f9279857931dbf64f942caf909076e40fd5bd5ed8d30b53ff922941"PRIVATE KEY="verity_key.pem"certificate="verity_cert.pem"ecological ${SOURCE} |tr-d'\norte' >roothash.txtopenssl smiles-plate-nocertificates-noattr-tracks-em roothash.TXT \-ink key ${PRIVATE KEY} -subscriber ${certificate} -go there-out rootash.TXT.signed

Don't forget to request signatures in the kernel command line parameters of the embedded target by adding:

dm_verity.require_signatures=1

Then finally we can mount the filesystem from our initramfs:

MAPPER_NAME="verity_example"PART_SRC_EXT4="/dev/mmcblk0p1"METADATA_HASH_DEV="/dev/mmcblk0p2"SOURCE="b96a69664f9279857931dbf64f942caf909076e40fd5bd5ed8d30b53ff922941"truth setting \--restart-on-corruption--ignore-zero-blocks--fuente-Hash-business=roothash.TXT.signed \ create"${MAPPER_NAME}" "${PART_SRC_EXT4}"\"${METADATA_HASH_DEV}" "${ROOT OF ROOT}"mkdir-pag/newrootmount/developer/mapper/ps{MAPPER_NAME} /newrootswitch_root/new root/sbin/Start

How can I do this without an initramfs? CONFIG_DM_INIT=y

CONFIG_DM_INIT is a kernel mechanism that allows you to pass a device allocation table to the kernel at boot time from kernel command line parameters.

So from a command line point of view, the userspace command transforms from this:

truth setting--ignore-zero-blocks\create"dm-0" "/dev/mmcblk0p1" "/dev/mmcblk0p2"\"b96a69664f9279857931dbf64f942caf909076e40fd5bd5ed8d30b53ff922941"

To do this, we manually pass the DM table information to the kernel:

direct message-modification.cry="true,,,ro,0 131072 true 1 /dev/mmcblk0p1 /dev/mmcblk0p2 4096 4096 16384 1 sha256\b96a69664f9279857931dbf64f942caf909076e40fd5bd5ed8d30b53ff922941\2a4c7638f03b92bdb92d7284a742e0c4407c9ef65fdf2a7ea78ed02fde4a518b 1 ignore_zero_blocks"

To break this down a bit more:

direct message-modification.cry="<name>,<uuid>,<minor>,<flags>,[dm_table_params {dm_verity_params}]"Uno de dm_table_params="<initial_sector> <num_sectors> <target_type> <dm_verity_parameters>"E dm_verity_params="<version> <development> <development_hash> <data_block_size> <hash_block_size> <number_data_blocks>\<hash_start_block> <algoritmo> <digest> <salt> [<#opt_params> <opt_params>]"

So, in our example:

Name="TRUE"uuid="unused/disabled"smaller="unused/disabled"banderas="Ro"dm_table_params=home_sector="0"num_sectors="131072"target type="TRUE"goal_args="dm_verity_params"version="1"developer="mmcblk0p1"hash_dev="mmcblk0p2"data_block_size="4096"hash_block_size="4096"num_data_blocks="16384"hash_start_block="1"algorithm="sha256"to digest="b96a69664f9279857931dbf64f942caf909076e40fd5bd5ed8d30b53ff922941"sal="2a4c7638f03b92bdb92d7284a742e0c4407c9ef65fdf2a7ea78ed02fde4a518b"

From the "veritysetup format" command above, we can see how many of these parameters are derived:

VERITY header information e.g.ext4.metadataUUID: e17b33f3-ce02-4d9b-a0a8-90c85ebe3240hash type: 1data blocks: 16384data block size: 4096Hash block size: 4096hashing algorithm: sha256Sal: 2a4c7638f03b92bdb92d7284a742e0c4407c9ef65fdf2a7ea78ed02fde4a518broot hashish: b96a69664f9279857931dbf64f942caf909076e40fd5bd5ed8d30b53ff922941

For the number of sectors, this is calculated using Verity Data Blocks * Verity Data Block Size / Sector Size. Assuming your slice size is 512 (the most common), we have 16384*4096/512 = 131072.

On U-Boot I like to set this up similar to:

setenv DATA_BLOCKS16384setenv DATA_BLOCK_SIZE4096setenv DATA_SECTORS131072setenv HASH_BLOCK_SIZE4096setenv HASH_ALGsha256setenv WILL2a4c7638f03b92bdb92d7284a742e0c4407c9ef65fdf2a7ea78ed02fde4a518bsetenv ROOT_HASHb96a69664f9279857931dbf64f942caf909076e40fd5bd5ed8d30b53ff922941setenv DATA_DEVmmcblk0p1setenv DATA_META_DEVmmcblk0p2setenv bootargs ${starts}direct message-modification.cry="true,,,ro,0ps{DATA_SECTORS} true 1 /dev/ps{DATA_DEV}/dev/ps{DATA_META_DEV}ps{HASH_BLOCK_SIZE}ps{DATA_BLOCK_SIZE}ps{DATA BLOCKS} 1ps{HASH_ALG}ps{ROOT_HASH}ps{SAL} 1 ignore_zero_blocks"fuente=/developer/direct message-0dm_verity.require_signatures=1

Note: /dev/dm-0 is the first device mapper created by this initial device mapping procedure. If this is your rootfs, you should also set root=/dev/dm-0 as we did above.

Wait, what about the initial verification of the root hash signature? Where did that go?

Nice catch, we can no longer use the OpenSSL+initramfs method. Unfortunately, DM_VERITY_VERIFY_ROOTHASH_SIG does not support direct mapping either, as it uses the kernel keystore system and does not provide a way to configure keystore via kernel command line arguments.

Alright, let's fix it. We'll add a new verity table parameter called "root_hash_sig_hex" where we can define the input root hash signature, without the keychain.

From: Nathan Barrett-Morrison <nathan.morrison@timesys.com>Data: fourth,30March2022 10:57:25-04:00Subject: [PATCH1/1] DM-Verity: Add the root_hash_sig_hex parameter to the initial mapping of the device verity so that we can pass a roothash signature via /proc/cmdline. This allows the ability to use DM_VERITY_VERIFY_ROOTHASH_SIG in conjunction with the above device mapping---controllers/md/dm-verity-objetivo.c |8+++- controladores/md/dm-verity-verify-sig.c |63++++++++++++++++++++++++++++++++ controladores/md/dm-verity-verify-sig.h |19++++++++-3files changed,87inserts (+),3exclusions (-)diff --git a/drivers/md/dm-verity-target.c b/drivers/md/dm-verity-target.cindex 3fb02167a590..047dd9a10264 100644--- a/drivers/md/dm-verity-objetivo.c+++ b/drivers/md/dm-verity-objetivo.c@@ -930,7 +930,13 @@ static int verity_parse_opt_args(struct dm_arg_set *as, struct dm_verity *v,se(r) return r; continue;-+ } más si (verity_verify_is_hex_sig_opt_arg(arg_name)) {+ r = verity_verify_hex_sig_parse_opt_args(como, v,+check_arguments,+ &argc, arg_name);+ yes(r)+ returns r;+ continue;} ti->error = "Unrecognized verification function request";diff --git a/drivers/md/dm-verity-verify-sig.c b/drivers/md/dm-verity-verify-sig.cindex 919154ae4cae..906e5a2034b5 100644--- a/drivers/md/dm-verity-verify-sig.c+++ b/drivers/md/dm-verity-verify-sig.c@@ -28,6 +28,12 @@ bool verity_verify_is_sig_opt_arg(const char *arg_name)DM_VERITY_ROOT_HASH_VERIFICATION_OPT_SIG_KEY)); }+bool verity_verify_is_hex_sig_opt_arg(const char *arg_name)+{+ return (!strcasecmp(nombre_arg,+ DM_VERITY_ROOT_HASH_VERIFICATION_OPT_HEX_SIG_KEY));+}+static int verity_verify_get_sig_from_key(const char *key_desc, struct dm_verity_sig_opts *sig_opts) {@@ -64,6 +70,33 @@ static int verity_verify_get_sig_from_key(const char *key_desc,right return; }+static int verity_verify_get_sig_from_hex(const char *key_desc,+ estructura dm_verity_sig_opts *sig_opts)+{+ int ret = 0, i = 0, j = 0;+ uint8_t byte[3] = {0x00, 0x00, 0x00};+ long result;++ sig_opts->sig = kmalloc(strlen(key_desc)/2, GFP_KERNEL);+ si (!sig_opts->sig) {+ right = -ENOMEME;+ go to the end;+ }++ sig_opts->sig_size = strlen(key_desc)/2;++ for(i = 0, j = 0; i < strlen(key_desc)-1; i+=2, j+=1){+ byte[0] = key_desc[i];+ byte[1] = key_desc[i+1];+ kstrtol(byte, 16, &result);+ sig_opts->sig[j] = result;+ }++fim:++ right return;+}+int verity_verify_sig_parse_opt_args(struct dm_arg_set *as, struct dm_verity *v, struct dm_verity_sig_opts *sig_opts,@@ -93,6 +126,36 @@ int verity_verify_sig_parse_opt_args(struct dm_arg_set *as,right return; }+int verity_verify_hex_sig_parse_opt_args(struct dm_arg_set *as,+ estructura dm_verity *v,+ estructura dm_verity_sig_opts *sig_opts,+ unsigned int *argc,+ carácter const *arg_name)+{+ structure dm_target *ti = v->ti;+ enter = 0;+ const char *sig_key = NULL;++ si (!*argc) {+ ti->error = DM_VERITY_VERIFY_ERR("Signing key not specified");+ return -SINGLE SELECTION;+ }++ sig_key = dm_shift_arg(como);+ (*argc)--;++ ret = verity_verify_get_sig_from_hex(sig_key, sig_opts);+ se (right < 0)+ ti->error = DM_VERITY_VERIFY_ERR("Invalid key specified");++ v->signature_key_desc = kstrdup(sig_key, GFP_KERNEL);+ si (!v->signature_key_desc)+ return -ENOMEM;++ right return;+}++/* * Verify_verify_rootash - Verifies the hash veracity of the device root hash * using built-in trust keys.diff --git a/drivers/md/dm-verity-verify-sig.h b/drivers/md/dm-verity-verify-sig.hindex 19b1547aa741..2be00114becc 100644--- a/drivers/md/dm-verity-verificar-sig.h+++ b/drivers/md/dm-verity-verify-sig.h@@ -10,6 +10,7 @@#define DM_VERITY_ROOT_HASH_VERIFICATION "Verificación DM Verity Sig" #define DM_VERITY_ROOT_HASH_VERIFICATION_OPT_SIG_KEY "root_hash_sig_key_desc"+#define DM_VERITY_ROOT_HASH_VERIFICATION_OPT_HEX_SIG_KEY "root_hash_sig_hex"struct dm_verity_sig_opts { unsigned int sig_size;@@ -23,11 +24,13 @@ estructura dm_verity_sig_opts {int verity_verify_root_hash(const void *data, size_t data_len, const void *sig_data, size_t sig_len); bool verity_verify_is_sig_opt_arg(const char *arg_name);-+bool verity_verify_is_hex_sig_opt_arg(const char *arg_name);int verity_verify_sig_parse_opt_args(struct dm_arg_set *as, struct dm_verity *v, struct dm_verity_sig_opts *sig_opts, unsigned int *argc, const char *arg_name);-+int verity_verify_hex_sig_parse_opt_args(struct dm_arg_set *as, struct dm_verity *v,+ estructura dm_verity_sig_opts *sig_opts,+ int sin signo *argc, const char *arg_name);void verity_verify_sig_opts_cleanup(struct dm_verity_sig_opts *sig_opts); #outro@@ -45,6 +48,11 @@ bool verity_verify_is_sig_opt_arg(const char *arg_name)returns false; 🇧🇷+bool verity_verify_is_hex_sig_opt_arg(const char *arg_name)+{+ returns false;+}+int verity_verify_sig_parse_opt_args(struct dm_arg_set *as, struct dm_verity *v, struct dm_verity_sig_opts *sig_opts, unsigned int *argc, const char *arg_name)@@ -52,6 +60,13 @@ int verity_verify_sig_parse_opt_args(struct dm_arg_set *as, struct dm_verity *v,volver -SINGLE SELECTION; }+int verity_verify_hex_sig_parse_opt_args(struct dm_arg_set *as, struct dm_verity *v,+ estructura dm_verity_sig_opts *sig_opts,+ int sin firmar *argc, const char *arg_name)+{+ return -SINGLE SELECTION;+}+void verity_verify_sig_opts_cleanup(struct dm_verity_sig_opts *sig_opts) { }

Therefore, this patch allows the kernel to receive the roothash signature as a hexadecimal-formatted string from command line arguments and convert it back to raw data when copied to sig_opts->sig. This is done within the verity_verify_get_sig_from_hex() section of the patch.

Now that our kernel is patched, we can do the following in our build system:

SOURCE="b96a69664f9279857931dbf64f942caf909076e40fd5bd5ed8d30b53ff922941"PRIVATE KEY="verity_key.pem"certificate="verity_cert.pem"ecological ${SOURCE} |tr-d'\norte' >roothash.txtopenssl smiles-plate-nocertificates-noattr-tracks-em roothash.TXT \-ink key ${PRIVATE KEY} -subscriber ${certificate} -go there-out rootash.TXT.firmadoxxd-p sign.TXT|tr-d'\norte'#This will generate a hex dump of a signature that looks like:#3081f906092a864886f70d010702a081eb3081e8020101310f300d06096086480165030402010500300#b06092a864886f70d0107013181c43081c1020101301b30163114301206035504030c0b6578616d706c65#2e636f6d020101300d06096086480165030402010500300d06092a864886f70d01010105000481806f196#a3081d941d22de98b34fc56f5c1b7ffc827ccd1307be9017bb6773da49026ef556668185c68b30562a60c#ec635bbe0a52ad92b878dac9e4ad146f5d36101b48ec5f522d12772b8e915524586598c8659494fba427e#e46c02043f30f45e096a1b9a987fc200b815f43bb48d42ad2d64b3f632f5332e6f74890b4541b467d

Then, from our target system's boot arguments, we can add the new "root_hash_sig_hex" parameters:

setenv DATA_BLOCKS16384setenv DATA_BLOCK_SIZE4096setenv DATA_SECTORS131072setenv HASH_BLOCK_SIZE4096setenv HASH_ALGsha256setenv WILL2a4c7638f03b92bdb92d7284a742e0c4407c9ef65fdf2a7ea78ed02fde4a518bsetenv ROOT_HASHb96a69664f9279857931dbf64f942caf909076e40fd5bd5ed8d30b53ff922941setenv DATA_DEVmmcblk0p1setenv DATA_META_DEVmmcblk0p2setenv VERITY_SIGNATURE3081f906092a864886f70d010702a081eb3081e8020101310f300d06096086480165030402010500300 b06092a864886f70d0107013181c43081c1020101301b30163114301206035504030c0b6578616d706c652e636f6d020101300d 06096086480165030402010500300d06092a864886f70d010101050004818071fcaaf1b252a56448438e0a9350b7380a407b1e9 0ae869ec5062466b0eb6cc5358e253a9d57086c358220745bc60c2a6d8dbc30c02fb1714c9c98f10e0679b87deb0c19929675c8 fcf89f37c684f043583fca52729ffb6e928eb29b7ee0c9eab3a3b0809a4463f3c8d6d458745c9116a7df1677c707df6352f2323 13a62ce20setenv bootargs ${starts}direct message-modification.cry="true,,,ro,0ps{DATA_SECTORS} true 1 /dev/ps{DATA_DEV}/dev/ps{DATA_META_DEV}ps{HASH_BLOCK_SIZE}ps{DATA_BLOCK_SIZE}ps{DATA BLOCKS} 1ps{HASH_ALG}ps{ROOT_HASH}ps{SALT} 3 ignore_zero_blocks root_hash_sig_hexps{VERITY_SIGNATURE}"fuente=/developer/direct message-0dm_verity.require_signatures=1

Now you are really ready! Your kernel will check for DM-Verity filesystem rootash and boot without any requirement for an initramfs.

Other considerations

1) Here are all the kernel configuration options related to device mapping and veracity:

CONFIG_BLK_DEV=yCONFIG_BLK_DEV_LOOP=yCONFIG_MD=yCONFIG_BLK_DEV_DM=yCONFIG_BLK_DEV_MD=yCONFIG_DM_INIT=yCONFIG_DM_VERIDAD=yCONFIG_DM_VERITY_VERIFY_ROOTHASH_SIG=yCONFIG_SYSTEM_TRUSTED_KEYRING=yCONFIG_SYSTEM_TRUSTED_KEYS="verity_cert.pem"

2) Your verified file system is only as good as your chain of trust. Each stage of the boot process must be properly protected. Our Secure Boot article describes this in more detail.on here.

3) If your U-Boot environment can be manipulated such that dm_verity.require_signatures can be disabled, then root filesystem verification can easily be overridden. You might consider enabling this with a kernel patch like so:

From: Nathan Barrett-Morrison <nathan.morrison@timesys.com>Data: fourth,30March2022 10:58:20-04:00Subject: [PATCH1/1] DM-Verity: Requires dm-verity rootash signatures, cannot be disabled via /proc/cmdline---controladores/md/dm-verity-verify-sig.c |4++-1file changed,3inserts (+),1elimination(-)diff --git a/drivers/md/dm-verity-verify-sig.c b/drivers/md/dm-verity-verify-sig.cIndia 906e5a2034b5..b979e8e6b498 100644--- a/drivers/md/dm-verity-verify-sig.c+++ b/drivers/md/dm-verity-verify-sig.c@@ -14,10 +14,12 @@#define DM_VERITY_VERIFY_ERR(s) DM_VERITY_ROOT_HASH_VERIFICATION " " s-static bool require_signatures;+static bool require_signatures = true;+/*module_param(require_signatures, bool,0444🇧🇷 MODULE_PARM_DESC(require_signatures, "Verificar árbol hash roothash dm-verity");+*/#define DM_VERITY_IS_SIG_FORCE_ENABLED() \ (require_signatures != false)

4) Small amounts of data corruption can be automatically corrected with CONFIG_DM_VERITY_FEC. If you're interested in that, consider enabling this setting as well.

5) When booting from an MMC device, I noticed that the MMC partition enumeration was out of sync with the old device allocation handler's device lookup, leading to a race condition. That is, it would try to find the MMC partitions listed (mmcblk0p1, mmcblk0p2) before they were instantiated and failed. I fixed it with another patch:

From: Nathan Barrett-Morrison <nathan.morrison@timesys.com>Data: fourth,30March2022 10:54:01-04:00Subject: [PATCH1/3] DM-Verity: Wait until10seconds for the eMMC/SD partitions to appear before dm_get_device() fails---controllers/md/dm-verity-objetivo.c |sixteen++++++++++++----1file changed,12inserts (+),4exclusions (-)diff --git a/drivers/md/dm-verity-target.c b/drivers/md/dm-verity-target.cindice 711f101447e3..3fb02167a590 100644--- a/drivers/md/dm-verity-objetivo.c+++ b/drivers/md/dm-verity-objetivo.c@@ -18,6 +18,7 @@#include "dm-verity-verify-sig.h" #include <linux/module.h> #include <linux/reboot.h>+#include <linux/delay.h>#define DM_MSG_PREFIX "verdadero"@@ -998,10 +999,17 @@ static int verity_ctr(struct dm_target *ti, argc sin firmar, char **argv)} v->version = num;- r = dm_get_device(ti, argv[1], FMODE_READ, &v->data_dev);- se (r) {- ti->error = "Data device search failed";- go to evil;+ //Wait up to 10 seconds for devices to become available --+ //wait_for_device_probe() handles it, but eMMC/SD probe ends+ //e dm_get_device() fails before eMMC/SD partitions are found+ para(i = 0; i <= 100; i++){+ r = dm_get_device(ti, argv[1], FMODE_READ, &v->data_dev);+ se (r && i < 100) {+ msleep_interruptible(100);+ }if not(r){+ ti->error = "Data device search failed";+ go to evil;+ }} r = dm_get_device(ti, argv[2], FMODE_READ, &v->hash_dev);

Startup time comparisons

Testing on a relatively slower ARM processor (ADSP-SC589, ARMv7 500 MHz single core) shows some significant improvements. Note that this renderer is favorable for displaying the time difference here, as it has a slower initramfs load and unload time. Newer processors with eMMC, DDR, and faster cores will reduce this margin.

On this processor, there is a total boot time difference of 29.19 seconds.

On a faster multicore ARMv8+ processor, I think you would still see a significant 1-2 second difference in boot time. Initial device mapping can be a very important tool if you are trying to achieve a boot time goal of less than 10 seconds.

Help!

As always, we offerprofessional engineering servicesto help you with your project. If you would like us to integrate our implementation of security features, please callVigiShieldNombre, on your project, or just need another set of hands to help with security and general engineering of embedded software, we're here to help!