Secure Boot on Rock 5B

#1

I’m trying to enable Secure Boot on Rock 5B by burning RSA public key to OTP fuse.
Following the Rockchip_Developer_Guide_Secure_Boot_Application_Note_EN.pdf guide I was able sign and upload the signed firmware to the devices. As per the doc, the first time a signed firmware boots it should burn fuses automatically, but apparently it doesn’t happen as I’m still able to boot with unsigned firmware.

Have tried the same approach on other RK3566/RK3568 boards with no luck.

At the same time on RK3399, I was able to burn keys with EFuseTool and everything works.

1 Like
Let's Get WideVine Working
#2

I couldn’t get it to Secure Boot either, I could be wrong but from what I gather it’s the lack of mini loader on my end, and I can’t find any code in the build repository that indicates that the trust files get packed in to the idbloader for any rk35xx build

#3

From chapter “6.6 Programming OTP”:

If OTP program success, serial port print “otp write key success!!!”. If OTP program fail, serial
port print"otp write error: !!!".

I found out only the following loaders have the required logic:

$ grep -r "otp write key" rkbin/bin/rk35/
grep: rkbin/bin/rk35/rk3588_ramboot_v1.06.bin: binary file matches
grep: rkbin/bin/rk35/rk3568_miniloader_spinand_v1.15.bin: binary file matches
grep: rkbin/bin/rk35/rk356x_spl_nand_v1.14.bin: binary file matches

So for RK3588 the only suitable loader for enabling secure boot is rk3588_ramboot_v1.06.bin.

I created idbloader.img and signed it using the following commands:

$ ./uboot/bools/mkimage -n rk3588 -T rksd -d rk3588_ddr_lp4_2112MHz_lp5_2736MHz_v1.08.bin:rk3588_ramboot_v1.06.bin idbloader.img

$ rk_sign_tool ssr --key privateKey.pem --pubkey publicKey.pem --idb idbloader.img

but that doesn’t enable secure boot either (SecureMode = 0):

DDR Version V1.08 20220617
LPDDR4X, 2112MHz
channel[0] BW=16 Col=10 Bk=8 CS0 Row=17 CS=1 Die BW=16 Size=2048MB
channel[1] BW=16 Col=10 Bk=8 CS0 Row=17 CS=1 Die BW=16 Size=2048MB
channel[2] BW=16 Col=10 Bk=8 CS0 Row=17 CS=1 Die BW=16 Size=2048MB
channel[3] BW=16 Col=10 Bk=8 CS0 Row=17 CS=1 Die BW=16 Size=2048MB
Manufacturer ID:0xff 
CH0 RX Vref:27.7%, TX Vref:22.8%,0.0%
CH1 RX Vref:28.7%, TX Vref:23.8%,0.0%
CH2 RX Vref:28.7%, TX Vref:21.8%,0.0%
CH3 RX Vref:27.7%, TX Vref:22.8%,0.0%
change to F1: 528MHz
change to F2: 1068MHz
change to F3: 1560MHz
change to F0: 2112MHz
out
Boot1 Release Time: Feb 24 2022 10:23:56, version: 1.05 USB BOOT
ChipType = 0x32, 481
SecureMode = 0
atags_set_bootdev: ret:(0)
UsbBoot ...1079
powerOn 1340
Usb no Connecte. 6001342
Usb no Connecte. 12001344
Usb no Connecte. 18001349
Usb no Connecte. 24001357
1 Like
#4

@kirgene @ibebarrett Hi! Were you able to get the Secure Boot thing done? I was looking for some documentation and could not get anything more up-to-date than https://github.com/yunzhaoyu2050/rockchip_rv1126_rv1109_docs/blob/main/Kernel/NVM/Rockchip_Developer_Guide_Secure_Boot_Application_Note_EN.pdf

#6

(post withdrawn by author, will be automatically deleted in 24 hours unless flagged)

1 Like
#7

Hi There, thank you for posting your results, good to know!

And did you try flashing it with dd? Something like this?
sudo dd if=./out/u-boot/idbloader.img of=/dev/mtdblock0 bs=512 seek=64
sudo dd if=./out/u-boot/u-boot.itb of=/dev/mtdblock0 bs=512 seek=16384

#8

(post withdrawn by author, will be automatically deleted in 24 hours unless flagged)

1 Like
#9

If anyone is interested in enabling Secure Boot on their RK3588 device, I’ve released instructions and tools at my github. I don’t recommend doing it if you’re not capable of understanding C code and compiling it. I’ve made it as simple as possible, but it’s still a bit convoluted. Since enabling SB has a risk of bricking (hasn’t happened to me but…) I’ve also made it “difficult” in a few places to make sure you read the instructions correctly. If you don’t, you cannot enable SB.

4 Likes
#10

(post withdrawn by author, will be automatically deleted in 24 hours unless flagged)

2 Likes
#11

For those interested, we’ve successfully enabled Secure Boot (on a different board not Rock 5B), along with full disk encryption, and everything seems to be working smoothly. But yes, as @DualTachyon pointed out it was quite a bit of effort. It is even frustrating to realize that while this feature is actually supported by the hardware, yet documentation is scarce, and all board manufacturers we talked to do not support this feature.

2 Likes
#12

@gilbertchen and @DualTachyon can you please say what observation do you get when trying to load any unsigned bootloader after enabling secure boot using rkdeveloptool db xx.bin ? And @DualTachyon do you get a minimal uart output when loading your custom unsigned bootloader on a secured SoC?

We are trying to diagnose a board we have, that embeds RK3588S and refuses to load any bootloader, and while it gets recognized in maskrom, we have no clue why it is the case. Power and current are also in good figures. A different board can load any bootloader, rockchip binaries or DualTachyon’s custom one.

We have the feeling that the non-working one was locked up during manufacturing, or accidentally pre secured. So we’re trying to compare similar patterns to confirm. Ultimately we will try to enable secureboot on the working SoC and compare.
Lack of documentation and support from rockchip doesn’t make this easier.

#13

(post withdrawn by author, will be automatically deleted in 24 hours unless flagged)

#14

(post withdrawn by author, will be automatically deleted in 24 hours unless flagged)

#15

No it won’t accept any loader or custom loader. I am not even trying to get to DDR training. I used your custom bootloader to just setup a uart and display a test message. I also doubt that the uart subsystem is not working as the SoC manages to also setup the pull-ups and pull-downs on the GPIOs within the same PMU and I could measure voltage on them. Also the fact that the USB enumeration and entering maskrom work fine, indicate that the CPU is working to a certain extent.

One behaviour that can give a hint here, is that when uploading the “471” binary part, the uploading would work the first time (always no uart output), but the second time it just hangs until I have to reset the board. Is a RK3588(S) with secure boot enabled, behaves the same way?

#16

(post withdrawn by author, will be automatically deleted in 24 hours unless flagged)

#17

First @DualTachyon, thanks for the work on the bootloader, it helped a lot with debugging. We are talking about SPL loaders. Now, I followed your instructions and we managed to connect through SWD to the booting board in both forced maskrom and also when loading the custom bootloader, which initializes the SWD interface.

However, the two boards that are not booting do not respond via SWD and openocd shows that it cannot connect to the target. While these boards are powered up and able to enumerate USB and enter maskrom, we believe that they are alive. But no SWD access strengthens the indication of being boot secured.

One remark here about sending 471 multiple times before reset. Yes it would work once and needs reset for the booting boards. But for the non booting ones, it always succeeds in uploading the 471 data without reset and libusb never returns any error. Do you observe that when loading the wrong unsigned loader to the boot secured SoC on your end?

#18

(post withdrawn by author, will be automatically deleted in 24 hours unless flagged)

#19

Regarding the problem of reading and writing OTP failure, perhaps the enable bl32 part of this document can be solved: https://docs.radxa.com/en/rock5/rock5b/low-level-dev/rk_anti_copy_board

#20

We contacted the distributor. Otherwise, we will replace the SoC and try again. I will update about the results. Thank you.

#21

Update: We managed to replace the SoC with a new one, this time from a trusted source. This one worked, JTAG access and booting SPL loader work fine. Therefore we can confirm that the non-booting ones had a locked-up processor. It’s highly likely we got either some sort of engineering samples or something of an unknown channel.

Pay attention to whom you buy crucial parts from. This, for example, was a heavy price. But to be fair, we had a useful experience. @DualTachyon thanks again.