03-26-2019 07:21 AM
we are currently running into some issues trying to load an encrypted bitstream with u-boot.
First of all, we are not entirely sure if the encryption process of the bitstream was properly executed.
Creating an encrypted boot image with bootgen worked successfully and the FSBL could be loaded using an AES-key stored in BBRAM. According to https://www.xilinx.com/support/documentation/user_guides/ug570-ultrascale-configuration.pdf (among others), a bitstream is encrypted using the bitstream property BITSTREAM.ENCRYPTION, which unfortunately is not available in Vivado for the FPGA we're using (we tried other models for which this option was enabled).
Thus, we once again used bootgen to encrypt only the bitstream. But as of now, we still don't manage to have u-boot load it. The error message we receive is 'Crypto flags not matched with Image crypto operation', for which no further information can be found online.
When we encrypt the whole boot image using the following .bif file:
//arch = zynqmp; split = false; format = BIN
[destination_cpu = a53-0, bootloader, encryption = aes]./images/linux/zynqmp_fsbl.elf
[pmufw_image, encryption = aes]./images/linux/pmufw.elf
[destination_cpu = a53-0, exception_level = el-3, trustzone, encryption = aes]./images/linux/bl31.elf
[destination_cpu = a53-0, exception_level = el-2, encryption = aes]./images/linux/u-boot.elf
[offset=0x00200000, encryption = aes]./images/linux/recovery_fpga.bin
[offset=0x00800000, encryption = aes]./images/linux/recovery_image.ub
[offset=0x01800000, encryption = aes]./images/linux/default-config.jffs2
[offset=0x01FE0000, encryption = aes]./images/linux/uenv.bin
[offset=0x02000000, encryption = aes]./images/linux/fpga.bin
[offset=0x02600000, encryption = aes]./images/linux/image.ub
and the bootgen command bootgen -image ./scripts/bif/fpga.bif -p $PARTNAME -w on -arch zynqmp -process_bitstream bin -encrypt bbram, the FSBL loads but the PMU-FW doesn't run. Some more information: fpga.bin is our generated already encrypted bitstream using another .bif file.
We're slowly running out of ideas of what to do. Can someone help us?
04-05-2019 02:21 AM - edited 04-05-2019 02:41 AM
Quick update: We forgot the line [keysrc_encryption]bbram_red_key. After applying this fix, FSBL loads all partitions, encrypted and decrypted alike.
Alas, we are now facing a new problem. While we have managed to load an encrypted bitstream with the FSBL, it doesn't load the U-boot after exiting from the FSBL, even though the debug outpout suggests that all partitions (including the U-boot partition) have been loaded successfully.
On the other hand, if we configure the bitstream to be loaded by U-boot, U-boot will load normally but won't load the encrypted (and authenticated) bitstream, no matter if we load it with the command fpga loads or zynqmp secure. It also makes no difference if we load the bitstream from memory or via TFTP. The error behaviour we get is either the already mentioned Crypto flags not matched with Image crypto operation or U-boot just freezes and won't respond to any input anymore.
Attached you can find the currently used .bif.
I hope that someone can help us with this new, updated problem now.
04-05-2019 11:24 AM - edited 04-05-2019 11:24 AM
Hi @thuy.tran ,
To answer question on loading secure bitstream in u-boot,
Its not supported. Encryption only bitstream loading from device key is not supported feature.
which version you are using?
You can try secure bit programming using userkey(copy the 32bit key to .txt file) and provide the address of this key in fpgas command
04-08-2019 05:24 AM - edited 04-08-2019 05:25 AM
Thank you a lot for your reply.
We found the issue you were referring to under this link: https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842432/Authentication+and+decryption+at+u-boot and as I've already mentioned in my second part to the question, already tried to couple encryption with authentication. After reading your reply, I tried to give the user key solution a try (attached is the .bif we used). Unfortunately, the steps given under the beforementioned link didn't work for us since our encrypted FSBL cannot load if we put kup_key as the keysrc_encryption instead of the bbram_red_key.
Trying to provide the user key but with keysrc_encryption set to bbram_red_key, we again receive Crypto flags not matched with Image crypto operation. The command used was fpga loads 0 0x02000000 0x600000 1 1 0x00800000. Can you help me with that? We use the Xilinx U-Boot released together with Vivado 2018.2.
04-12-2019 07:40 AM
04-24-2019 05:56 AM
Thank you for your reply. We've already tried out all combinations for the fpga loads crypto flags. The two results we get is either the beforementioned Crypto flags not matched with Image crypto operation or U-Boot completely freezes. Unfortunately, we could not find anything that explains U-Boot's behavior.
06-27-2019 07:56 PM
I encountered and fixed a bug that may be related to your problem. I was playing with u-boot's `zynqmp aes` command, and found that it did not work as expected with a KUP key. Dumping the contents of the XSecure_AesParams structure showed that the "Key" entry had the wrong value, while the other members had the correct values as generated and passed in from u-boot.
Eventually I realized that the problem was because of u-boot not flushing its cache out for this entry. It does flush the cache for the contents being pointed at by the structure, but it doesn't flush the addresses holding the structure itself. BTW, the structure sits on u-boot's stack.
Please see the attached patch against u-boot from https://github.com/Xilinx/u-boot-xlnx.git, on tag xilinx-v2018.3.
You might be encountering a similar bug in your attempts to authenticate/decrypt. I did not look at the code of the `fpga loads` command, but you might find a similar mistake in the code there. Good luck.