UBIFS authentication for rootfs and keyring

Hi

It is not possible to mount UBIFS, even RO, without key added to kernel keyring and then the name of that key is passed over kernel command line to UBIFS. Without key created using keyctl at runtime!!! I get

UBIFS error (ubi0:5 pid 1): ubifs_read_superblock: authenticated FS found, but no key given

According do docs, certificate provided via CONFIG_SYSTEM_TRUSTED_KEYS, and then used to construct UBIFS image with mkfs.ubifs --auth-key and --auth-cert arguments, should be enough to mount UBIFS read only. This doesn’t seem to be true. All is fine though, if I create key using keyctl, which would be used for further UBIFS modifications (if any mods at all), and then use name of that key in mount command options.

Perhaps it was as intended prior to this patch, I don’t know. But as it is currently, seems preventing usage of rootfs on UBIFS authentication. I wonder how could I use UBIFS authentication for whole rootfs. There’s no way, or I don’t know how to keyctl via DT or perhaps kernel config. Looks like I either need to create driver, which would feed kernel with required key, or perhaps use small initramfs, which would create key, and then mount the most of real rootfs after that. Are there easier options? RO rootfs could be OK. Ability to RW remount with key created could be even better.

Thanks

Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!

Did you like my answer?

:+1: :-1:


Hello,

It seems you’re encountering issues with mounting a UBIFS as read-only without manually adding a key to the kernel keyring using keyctl. This is because UBIFS with authentication requires a key to verify the filesystem’s integrity.

When using UBIFS with authentication, a key is needed to decrypt or verify the filesystem’s metadata. Typically, this involves creating a key with keyctl and passing its name during the mount operation.

To automate this process and avoid manual key addition at runtime, consider the following options:

  1. Initramfs Approach: You can use an initramfs to handle key creation and addition to the kernel keyring before the main root filesystem is mounted. This involves scripting the key creation process in the initramfs, ensuring the key is available when the root filesystem is mounted.

  2. Custom Kernel Module or Driver: Developing a custom kernel module or driver that automatically adds the required key to the kernel keyring during boot is another solution. This requires kernel development expertise and thorough testing to ensure stability and security.

Unfortunately, there is no direct method to add keys via device tree or kernel configuration in the current Linux kernel. Therefore, runtime solutions like initramfs or custom drivers are necessary.

If a read-only root filesystem is sufficient for your needs, TorizonCore’s default setup might be beneficial. However, for UBIFS authentication, the above methods would be necessary to automate key management.

I hope this helps clarify your options.

Best regards,
Toradex AI Assistant.

Please, also check if these links can help you solve your problem:

https://www.kernel.org/pub//linux/kernel/v5.x/ChangeLog-5.16.19

Capacitive touch display 7" doesn't work with iMX6ULL and Aster.

Greetings @Edward,

Just to chime in a bit, are you interested in this for one of our raw nand colibri i.mx7 modules?

Admittedly we haven’t invested any signifcant time or resources with regards to security on our older raw nand modules. Especially since all of our newer and to-be-released modules don’t use UBIFS anyways.

Best Regards,
Jeremias

Right, it’s for Colibri iMX7D with raw NAND.
I just expected someone has it implemented. Looks like it is as usually with Linux features, you need to use files, planes and choppers to make it working.

Well with our limited knowledge on how raw NAND works with these features. It does appear that despite adding keys via CONFIG_SYSTEM_TRUSTED_KEYS, there is no effect. To be completely honest, it’s not likely the team will invest significant time on raw NAND/ubifs devices, with regards to security in the near future.

Perhaps either the linux security or ubifs mailing lists can provide better guidance on this point.

Best Regards,
Jeremias

OK, I understand. Yeah, there’s a lot of variuos lists and forums on the Earth, I can’t participate in all of them.

Thanks and Best Regards,
Edward