fix(security): Correct key flow diagram and text around it for AM64X#654
fix(security): Correct key flow diagram and text around it for AM64X#654jsuhaas22 wants to merge 2 commits intoTexasInstruments:masterfrom
Conversation
|
@jsuhaas22 let's enable the secure boot doc for am62x platforms in general, for am62l we should also highlight the FIT signing part |
0905fa3 to
4c41802
Compare
For AM62x and AM62P, I have added changes to include the doc. AM62L will require more work, so I will send a separate PR for that in a day or two. |
| U-boot: | ||
|
|
||
| The ti-u-boot source is a project used to create tiboot3.bin, tispl.bin, and u-boot.img. To create tiboot3.bin for AM64x family devices, u-boot builds R5 SPL and | ||
| The ti-u-boot source is a project used to create tiboot3.bin, tispl.bin, and u-boot.img. To create tiboot3.bin for Sitara family devices, u-boot builds R5 SPL and |
There was a problem hiding this comment.
Better to use K3 instead of Sitara
@jsuhaas22 sure, please address the relevant comments by the bot, looks fine otherwise. |
4c41802 to
5ae0b72
Compare
@shiva-ti Done. There are still some warnings left but those are invalid. |
5ae0b72 to
ab2bac8
Compare
| Kernel/DTB/initfamfs. This is accomplished by calling into TIFS via TI-SCI (Texas Instruments System controller Interface). This allows us to use | ||
| the same signing/encrypting tools used to authenticate the first-stage image. For more infomation using TI_SCI methods refer to the | ||
| `TISCI User Guide <https://software-dl.ti.com/tisci/esd/22_01_02/index.html>`__. | ||
| We offer methods for U-Boot's SPL loader to securely verify and encrypt the U-Boot proper. U-Boot calls TIFS through TI-SCI (Texas Instruments System Controller Interface) |
There was a problem hiding this comment.
@jsuhaas22 It should be "verify and decrypt the U-Boot proper".
Btw, we don't support the encrypted boot atleast for the U-Boot in the PSDK so it should only be "verify the U-Boot proper".
There was a problem hiding this comment.
The fitImage box shows "u-boot-dtb*.dtb". Is it correct? It should be Kernel DTBs, right?
The key-flow diagram and the information around it in AM64X's Secure Boot page state that U-Boot uses TI-SCI to authenticate the kernel image. This is no longer the case: U-Boot verifies the kernel image using the fitImage key contained in it without invoking TIFS. Therefore change the docs to reflect this. Signed-off-by: Suhaas Joshi <s-joshi@ti.com>
ab2bac8 to
89adb86
Compare
|
@p-shivhare-ti Addressed your comments. |
StaticRocket
left a comment
There was a problem hiding this comment.
Acronyms should follow their definitions, not the other way around. File roles should be prioritized when they can be.
| Secure boot has layers. Some layers are trusted more than others. Secure ROM has the highest trust and REE (Runtime Execution | ||
| Environment) non-trustzone user-space applications have the least. If any higher trust code is to be loaded by a lower trust entity, it must be verified |
There was a problem hiding this comment.
| Secure boot has layers. Some layers are trusted more than others. Secure ROM has the highest trust and REE (Runtime Execution | |
| Environment) non-trustzone user-space applications have the least. If any higher trust code is to be loaded by a lower trust entity, it must be verified | |
| Secure boot has layers. Some layers are trusted more than others. Secure ROM has the highest trust and Runtime Execution | |
| Environment (REE) non-trustzone user-space applications have the least. If any higher trust code is to be loaded by a lower trust entity, it must be verified |
| Kernel/DTB/initfamfs. This is accomplished by calling into TIFS via TI-SCI (Texas Instruments System controller Interface). This allows us to use | ||
| the same signing/encrypting tools used to authenticate the first-stage image. For more infomation using TI_SCI methods refer to the | ||
| `TISCI User Guide <https://software-dl.ti.com/tisci/esd/22_01_02/index.html>`__. | ||
| We offer methods for U-Boot's SPL loader to securely verify the U-Boot proper. U-Boot calls TIFS through TI-SCI (Texas Instruments System Controller Interface) |
There was a problem hiding this comment.
| We offer methods for U-Boot's SPL loader to securely verify the U-Boot proper. U-Boot calls TIFS through TI-SCI (Texas Instruments System Controller Interface) | |
| We offer methods for U-Boot's SPL loader to securely verify the U-Boot proper. U-Boot calls TIFS through Texas Instruments System Controller Interface (TI-SCI) |
|
|
||
| The ti-linux-firmware is a TI repository where all firmware releases are stored. Firmwares for a device family can also be found in the pre-built SDK | ||
| under <path-to-tisdk>/board-support/prebuilt-images/am64xx-evm. Binman expects to find the device firmware with the following appended to u-boot build command: | ||
| under <path-to-tisdk>/board-support/prebuilt-images/<evm>. Binman expects to find the device firmware with the following appended to u-boot build command: |
There was a problem hiding this comment.
| under <path-to-tisdk>/board-support/prebuilt-images/<evm>. Binman expects to find the device firmware with the following appended to u-boot build command: | |
| under :file:`<path-to-tisdk>/board-support/prebuilt-images/<evm>`. Binman expects to find the device firmware with the following appended to u-boot build command: |
1df2f56 to
b683f64
Compare
Currently, the secure boot section is tailored for AM64x. But the same information is applicable to non-AM64x SoCs, that is AM62x, AM62P. Therefore generalize the page and add it these other devices' TOCs. In addition, fix the language in the file to simplify it by changing a few passive voice statements into active voice, using easier words etc. Signed-off-by: Suhaas Joshi <s-joshi@ti.com>
b683f64 to
526f6c6
Compare
|
Addressed your comments, @StaticRocket |
The key-flow diagram and the information around it in AM64X's Secure Boot page state that U-Boot uses TI-SCI to authenticate the kernel image. This is no longer the case: U-Boot verifies the kernel image using the fitImage key contained in it without invoking TIFS. Therefore change the docs to reflect this.
New diagram:
