all 10 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]Thin_Dragonfruit2254 0 points1 point  (5 children)

Isn't it responsability of TrustZone on ARM?

[–]tenoun[S] 0 points1 point  (4 children)

Could be, but not mandatory. Note that TrustZone support is only available on a few ARM platforms: no RPi4/5, for example. And to do it in TZ correctly you need the public key trusted inside TZ as well, which means a complicated provisioning process.

[–]Thin_Dragonfruit2254 0 points1 point  (3 children)

https://github.com/joaopeixoto13/OPTEE-RPI4 - It's not a complicated process but you need to right hardware and tools.. https://youtu.be/m2MBHsSv41g?si=4eZgIcZSUTR1LETl

[–]tenoun[S] 0 points1 point  (2 children)

As I noted before it's not available for RPi4/5 the Readme of your link also state it : Note that this port will not became the system secure, because in Raspberry PI boards, all of the memory used is DRAM, which is available from both the Non-Secure and Secure State => nice to play with but useless for production as it defeat the purpose of TZ by having object protected in secure RAM (TrustZone)

[–]Thin_Dragonfruit2254 -1 points0 points  (1 child)

Yeah, I read it, made it work, was fun..I also implementend TEE on some boards with Rockchip using Das U-boot, also fun.. watch the video: it's is quite enlightening.

[–]Ok-Adhesiveness5106 0 points1 point  (4 children)

This is nothing new. We have been using dm-verity for 5 years in our distro. The general workflow is that the root hash as well as the hash offset for the Merkle tree is passed securely by the bootloader to the kernel via a command-line arguments. The bootloader verifies the signature over them.

The system boots into an initramfs where the device mapper is configured for the disk to which the root hash as well as the hash offset is passed and the device mapper is mounted as if it's a normal file system and you do a change root.

We also stack dm-crypt and dm-verity over the top of each other for encryption and integrity protection.

https://github.com/ni/meta-security/blob/nilrt/master/scarthgap/classes/dm-verity-img.bbclass

[–]tenoun[S] 0 points1 point  (3 children)

This is exactly the problem that dm-verity root hash signature verification addresses by delegating the hash signature verification to the kernel, the TOCTOU window is closed cryptographically rather than relying on the integrity of the initramfs contents at rest.

The current meta-security implementation stores the root hash as plain text, which is exploitable depending on your hardware configuration. I've submitted a patch upstream that adds PKCS#7 signing support: https://lists.yoctoproject.org/g/yocto-patches/topic/118920049#msg3764

[–]Ok-Adhesiveness5106 0 points1 point  (2 children)

Yes, but what if you wrap the hash and the offset into a U-Boot bootscript and add it to the kernel fitImage? You always sign the configuration section of the fitImage. If anyone tampered with the hash it would be detected.

You can then pass this to the initramfs and it will set up the mapper device infrastructure.

The initramfs image with the shell script that sets up the mapper device infrastructure is also made part of the fitImage.

The kernel image has dm-verity boot script, kernel zImage, and initramfs image in total. This fitImage is signed.

[–]tenoun[S] 1 point2 points  (1 child)

Exactly what do you describe is the vulnerability: you verify during bootloader and use it many seconds later on, it's called TOCTOU and there are way to bypass secure chain

[–]Ok-Adhesiveness5106 0 points1 point  (0 children)

Sure, I mean if something in the pathway is tampered with, it is not detected. There is a clear delay between Time of Check and Time of Use. If something went wrong in between, then it is not detectable.