Securing Boot questions

According to the “Security” Section of the JetPack documentation:
nvl4t_docs/index.html#page/Tegra%2520Linux%2520Driver%2520Package%2520Development%2520Guide%2Fl4t_security.html%23wwpID0EGHA

NVIDIA provides reference code for TBoot-BPMP. TBoot-CPU, CBoot, TOS, BL-DTB.
Does anyone know where I can find these sources?

Is there more documentation on the Common Driver Framework (CDF) which is NVIDIA specific? I am thinking I may need to utilize a TPM during the boot process to ensure integrity.

Also, the “Security:Secureboot:Signing Boot Files” section of the docs:
nvl4t_docs/index.html#page/Tegra%2520Linux%2520Driver%2520Package%2520Development%2520Guide%2Fl4t_secureboot.html%23wwpID0ENHA

states that the boot binaries are signed as part of the flashing process. Does anyone know which of the boot binaries are signed? All of them including uboot, or only up to MB2? I want to ensure the system integrity all the way up to the OS boot so I need to understand / verify which checks are already in place but the docs are a little vague here.

Thanks!

hello David_N,

here’s path for BL-DTB, i would check others and get back to you.
R28.1/hardware/nvidia/platform/t18x

Does anyone know which of the boot binaries are signed?
you could running with --no-flash command, check the flash message to find the binary with “*.signed”

David_N,
A few clarification,

and for details on signing and key generation implementation, you should download secure boot package from ‘Download Page’.

  • There is no TPM support in Jetson TX2. You are free to add the support yourself from optional U-Boot.
  • Currently there is no source code for TBoot-BPMP / TBoot-CPU / CBoot @r28.1. Please let us know if this prevent you from doing product development.
  • Same for TOS but again please let us know your need and use cases for TOS. Thanks.

chuang,
Thanks for your reply and thanks for sharing the link to the training video on secure boot. That is a great presentation which helps to elucidate the boot process.

However, I am confused about the protection we gain from using secureBoot if the authentication / validation stops at CBoot. It seems to me that our protection would only cover the boot process as the SOC is initialized and would not provide any protection to ensure that the RichOS has not been altered.
I think it would be possible for someone to FLASH just a new version of u-boot or the Kernel in order to have more control over the system.
I would like to ensure that the entire boot process is covered, all the way to the RichOS. Presumably this would require CBoot to authenticate/validate u-boot and possibly for u-boot to validate the kernel in order to complete the chain of trust.
If you concur with this assessment, then I think it would be necessary to add support for signing the richOS, or for the CBoot sources to be released so that we could add that capability.

David_N,
Thanks for your further comment. You are basically correct. Jetson secure boot is to ensure chain of trust from power-up to the bootloader. This secure boot process is clearly defined and supported by the Jetson hardware. However, after bootloader, the kernel and OS varies a lots depending on the platform you select. That could be many flavors of Linux, Android, various real-time OS, Window, iOS …it’s not feasible for a hardware platform to define (in another sense to restrict) a clear support for so many dramatically different varieties of operating environment.

Having said that, our secure OS implementation will be based on the following document but removing Android-related dependency,
https://source.android.com/security/trusty/