Home/Support/Support Forum/Bad data CRC after enabled trustfence
Welcome to Digi Forum, where you can ask questions and receive answers from other members of the community.

Bad data CRC after enabled trustfence

+1 vote
I built orginal image dey-image-tiny for imx6ul starter and after added trustfence my linux kernel can't boot.

I got boot.scr Bad data CRC.

Has anyone had the same problem?

Regards,
Adrian

Update:
Linux version 4.14

uboot v2017.03

yocto 2.6

Update 2:

I tried it on yocto 3.0 and problem is still the same.
asked Jul 9 in Linux by adi1525 New to the Community (4 points)
edited Jul 11 by adi1525

Please log in or register to answer this question.

1 Answer

0 votes
 
Best answer
Did you close the device or is it still open? If you are not explicitly setting the TRUSTFENCE_DEK_PATH Yocto variable to "0", then the boot artifacts are not only signed, but encrypted as well. Look at the local.conf, are you setting it to a predefined path? If so there's no doubt that the boot is failing because, on an open device, encrypted artifacts cannot be booted properly. This explains the CRC error because, before running the bootscript, U-Boot parses information from its header and verifies that the script's CRC is correct. This obviously fails when the script is encrypted.

To verify this, on the development machine, open the boot.scr file in the tmp/deploy/images/<platform> directory of the Yocto project using a plain text editor. If you see nothing but meaningless binary, then it's encrypted.

To disable encryption and only have the project sign the artifacts so that they can be booted on an open device, add the following to the local.conf:

TRUSTFENCE_DEK_PATH = "0"
Then, before flashing the generated boot partition to the device, try opening the boot.scr file again. You will see some binary at the beginning of the file (this is the header parsed by U-Boot), then a perfectly legible U-Boot script, and finally, the binary CST/signature at the end of it.

Also, in case you run into more problems after this, rootfs encryption is also enabled by default, so booting the rootfs as you would normally do after flashing it will not work. You can either:

Follow the extra steps in the documentation to generate a SWU package and flash the encrypted rootfs: https://www.digi.com/resources/documentation/digidocs/embedded/dey/2.6/cc6/yocto-trustfence_t_secure-boot-set-up#program-the-encrypted-rootfs
Disable rootfs encryption entirely by adding TRUSTFENCE_INITRAMFS_IMAGE = "" to local.conf
answered Jul 18 by LeonidM Veteran of the Digi Community (3,654 points)
selected Jul 22 by adi1525
Thank you very much!
I didn't know that linux is encrypted by default and this was the issues. The information that image is encrypted by default should be in secure boot overwiew in documentation.

I saw that my boot script is clear binary file but I didn't get that it's mean it's encrypted.

Regards,
Adrian
you are welcome. Please click "Select answer" button if your question is resolved.
...