Secure Boot sequence on both ARM and DSP (NOR legacy boot mode)

Hi Giuseppe,

Giuseppe Ameno said:

s the above sequence correct?

The boot sequence that you have described is more or less accurate. Here are some corrections:

After the DSP and ARM images are decrypted and authenticated and placed in mDDR, the ARM core is take out of reset by providing the entry point of the ARM secondary bootloader, in other words there is no ARM ROM bootloader as the root of trust on the secure chip is only  DSP BOOT ROM.

Giuseppe Ameno said:

How do we specify the exit mode of the ROM bootloader (NOR legacy is a non-AIS boot mode...)?

Exit mode for all non-AIS boot modes is NON-SECURE so if you need to exit in SECURE state for some reason, you would need to use some other boot media. We wont recommend NOR legacy boot mode in case you plan to implement a secondary bootloader where secure kernel APIs need to used to authenticate and decrypt images.

Giuseppe Ameno said:

Can we have ARM and DSP images independently encrypted and signed? I assume we can't if the SK_setUserkey can only be called once per boot!

SK_setUserKey is used to encrypt the user Key structure using the random KEK device that is unique to each device so I am not sure I understand your question here. Are you asking if ARM and DSP images can be independently encrypted and signed and loaded in as modules. This is supported using SK_decryptMod API. 

Giuseppe Ameno said:

The DSP start first and run the DSP ROM bootloader. Meanwhile the ARM is in reset mode (?).

Yes, secure OMAPL138 is a DSP boot master device so DSP bootloader runs first after reset. ARM is in reset until the DSP gets it out of reset.

Giuseppe Ameno said:

The DSP Secondary bootloader is executed

1. The DSP and the ARM images are decrypted, authenticated and placed in mDDR
2. The ARM is taken out of reset
3. The DSP goes to sleep (?)

After the ARM is taken out of reset the DSP would need to be put into reset/sleep state. By deafult it would just idle. It can also optionally be directly asked to jump to application binary as at this point the DSP application image is already loaded into mDDR unless you want the ARM to start of the DSP execution of the application image. 

Giuseppe Ameno said:

Does the configuration of the BOOT pins apply to both ARM and DSP?

DSP bootloader is the only root of trust on the chip so the boot pins configuration only applies to the DSP 

Giuseppe Ameno said:

1. Is there a way to prevent the ARM ROM bootloader to run? Can we modify the ARM reset vector from within the DSP Secondary bootloader so that when the ARM runs it executes immediately the code in the mDDR?

As I mentioned earlier, when you bring ARM out of reset, there is no execution of ARM bootloader, you can directly get the ARM to start executing the ARM secondary bootloader by putting the right entry point using the PRU subsytem into the ARM reset vectors.

For reference code of how to wake up the ARM core from the DSP using PRUSS, please refer to the  example provided below:

0312.DSP.zip

Hope this helps

Regards,

Rahul

Thanks Rahul, that is very useful.

Just a couple of more things.

- Would the AIS NOR boot mode appropriate for a secondary bootloader running in secure context (SECURE_WITH_SK)? I assume so...

- If the DSP ROM bootloader exits in SECURE_WITH_SK mode, do we need to call the SK_setUserKey in the secondary bootloader before calling the SK_decryptMod?

- I assume in our case both DSP and ARM images will be independently encrypted using the CEK. In the secondary bootloader we will need to call the SK_decryptMod twice. Each time passing in the appropriate boot load module data.

Regards,

Giuseppe 

Giuseppe Ameno said:

Would the AIS NOR boot mode appropriate for a secondary bootloader running in secure context (SECURE_WITH_SK)?

Yes, AIS NOR boot mode would be appropriate for exiting in SEcure context with SECURE_WITH_SK as you can select the exit mode in the INI file used to create the secure AIS image.

Giuseppe Ameno said:

If the DSP ROM bootloader exits in SECURE_WITH_SK mode, do we need to call the SK_setUserKey in the secondary bootloader before calling the SK_decryptMod?

The API SK_setUserKey is provided basically to facilitate the process of binding the image. It enables developers to encrypt the software header (with the user key) with the device specific key. For all binary images that  needs to be authenticated and encrypted, you would need to use crypto APIs and  SK_decryptMod APIs.

Yes , in order to decrypt the ARM and DSP images, you would need to call the SK_decryptMod twice but since you are decrypting the images in the secondary bootloader, you will also need to implement a mechanism to load the binaries in the appropriate memory space. 

Please note the basic secure OMAPL138 device is designed only for IP protection through secure boot and doesn`t support runtime security features beyond memory protection.

Regards,

Rahul