Apalis iMX8 SOM
Ixora Carrier Board
Yocto Linux
DM-Crypt
We have an Apalis iMX8 SOM mounted on a Ixora Carrier Board.
We wish to evaluate drive encryption using DM-Crypt and CAAM secure keys per the attached document AN12714 Rev2.
I have successfully built and flashed a Yocto image per sections 3 and 4 of the attached document, iMX8 Devkit Procedure. According to the document, the image loaded per section 4 of the document should have support for DM-Crypt, however, when I check for that, it does not have the kernel options enabled. Specifically, when I run the command “dmsetup targets”, the command does not display an entry for “crypt” or “multipath”. Also, for example, when I run “zcat /proc/config.gz | grep CONFIG_DM_CRYPT”, the command returns “CONFIG_DM_CRYPT=m”, when it should return “CONFIG_DM_CRYPT=y”. I get the same return result for the other kernel options listed in the attached document AN12714 Rev2, the return state is “=m” not “=y”.
I am working to try and resolve this on my own, by rebuilding the Yocto image with a different configuration, and also by manually loading the kernel modules at run time, but if someone can provide assistance it would be appreciated.
To clarify are you building the NXP BSP image as specified in the document you referenced, or are you building one of our images and trying to integrate DM-Crypt support there?
In either case, how are you trying to set these kernel configs exactly?
I am building the image referenced in the document, however, I am open to trying one of your images instead, I just need the kernel support enabled. I have been trying to modify the defconfig file(s) to enable the kernel support, but so far I have not been successful.
Generally speaking the configs should still be fine if they are built as modules rather than built in directly (m vs y). You may have to manually load them as you said, but functionally should be the same after that.
But if you really desire to have them be built-in then you should be able to just configure this in the yocto build with a config fragment that gets sourced by the relevant Linux kernel recipe in the build. This should be the case for both ours and the NXP reference images. Assuming the NXP builds doesn’t do something strange that might interfere with this, but I can’t speak for their build. In any case a config fragment file like this should work just fine (as an example):
# From AN12714 CAAM support
# Enable DM-Crypt and its dependencies
CONFIG_BLK_DEV_DM=y
CONFIG_BLK_DEV_MD=y
CONFIG_MD=y
CONFIG_DM_CRYPT=y
CONFIG_DM_MULTIPATH=y
# Enable CAAM black key/blob driver and its dependencies (this is enabled, by default)
CONFIG_CRYPTO_DEV_FSL_CAAM_TK_API=y
CONFIG_CRYPTO_USER_API=y
CONFIG_CRYPTO_USER_API_HASH=y
CONFIG_CRYPTO_USER_API_AEAD=y
CONFIG_CRYPTO_USER_API_SKCIPHER=y
CONFIG_BLK_DEV_RAM_SIZE=300000
Now if the default kernel config already sets some of these options as a module then this might override/interfere with the behavior. But as I said module or built-in shouldn’t matter too much.
One issue is that at least one of the CONFIGs is missing. I thought I could just modify the defconfig file, but there are multiple defconfig files, and it’s not clear to me which one(s) are used during the build.
The next step would be to add a config fragment as you suggest, I’m just not sure where to place it in the layers.
I am using a Toradex Yocto build, and I am using EasyInstaller to flash it, here are the commands to pull it and initialize it:
So either you can create a bbappend to this build or if you’re lazy just modify the original recipe so that the config fragment file is referenced in the recipe’s SRC_URI.
If you’re referring to what branch of our build to use, the answer is it depends, but not master. Our master branch in Yocto is typically just to track and develop upstream changes and is not stable in any way, so I can’t really recommend it for customer use.
In general you either want our Dunfell or Kirkstone branches. Dunfell is what we based our version 5.X.Y images on and Kirkstone is for our 6.X.Y images. Either works but Kirkstone is newer and therefore has newer versions of things (including the Linux kernel version). Again, it depends and maybe for your purposes here it doesn’t really matter which you go with.
@jeremias.tx I have it working with the Dunfell branch, using a config fragment and adding
a SRC_URI_append command to the kernel .bb file. I am seeing if the same approach works with Kirkstone, will let you know.
