If I have an embedded system with a raw NAND flash, with a bad blocks table etc., as I understand it, the best way to have partitions is to have have them as UBI volumes on top of MTD. UBI takes care of wear levelling and MTD handles erase blocks and bad blocks. Some details regarding this are explained on this page.
On an embedded system, typically, the bootloader stages and the Linux kernel would be verified using hardware vendor-specific Secure Boot of some kind, and then the root file system would typically be in the form of ubiblock + dm-verity + squashfs as mentioned here. This would be read-only and dm-verity takes care of authentication.
To implement rw partitions, typically ubifs is used.
But for implementing secure storage aka read-writeable encrypted storage on a block device, I could use dm-crypt (LUKS2). How or where the decryption key comes from is out of scope of this question.
Question 1:
Can I use dm-crypt (LUKS2) on top of an UBI volume on a raw NAND flash?
The UBI page, as quoted below, implies that this is not possible, as any block device implemented on top of an UBI volume, must be read-only.
R/O block devices on top of UBI volumes
UBI allows the creation of block devices on top of UBI volumes with the following limitations:
- Read-only operation.
- Serialized I/O operation, but keep in mind the NAND driver core already serializes all I/O too.
Despite these limitations, a block device is still very useful for the purpose of mounting read-only, regular file systems on top of UBI volumes. Take, for example, squashfs, which can be used as a lightweight read-only rootfs on top of a NAND device. In this case, the UBI layer will take care of low-level details such as bit-flip handling and wear-levelling.
Question 2:
If I cannot use dm-crypt (LUKS2), then what are my alternatives?
