PROCESSOR-SDK-AM64X: AM64x rollback protection

Walter Stoll

Tool/software:

Hi team

We face some difficulties in understanding how rollback protection is implemented. This page https://software-dl.ti.com/tisci/esd/latest/6_topic_user_guides/secure_boot_signing.html?highlight=rollback#signing-an-unencrypted-binary-for-secure-boot claims, that the "System Firmware Software Revision Extension" shall be populated in the X.509 certificate in order to enforce rollback protection.

Therefore it should be theoretically possible to rollback protect each image that is signed with such a certificate.

However, according https://software-dl.ti.com/tisci/esd/10_00_08/6_topic_user_guides/key_writer.html?highlight=msv#supported-fields there exist only three eFuse fields dedicated to software revision information, namely SWREV-BOARDCONFIG, SWREV-SBL and SWREV-SYSFW.

Based on the documents available to us we assume that SYSFW implements rollback protection by checking the "System Firmware Software Revision Extension" comprised in a image certificate against
an according eFuse field.

This raises some questions:

Is our assumption correct ?
The tiboot3.bin image comprises multiple binaries that are signed with a single X.509 certificate (disregarding inner cert). However, the "System Firmware Software Revision Extension" holds only
one single number. How is this number mapped to the SWREV-BOARDCONFIG, SWREV-SBL and SWREV-SYSFW eFuse fields ?
There are no eFuse fields provided that keep software revision information for binaries kept in the tispl.bin and u-boot.img images (ATF, OPTEE, DTBs, A53 bootloader code). All available eFuse fields are
related to the tiboot3.bin image. Is it correct, that rollback protection is not supported for the tispl.bin and u-boot.img images (and therefore must be realized in sofware) ?
The SWREV-* fields are initialized by TI to a value of 1, correct ?
The SWREV-* fields are typically left untouched during commissioning (Keywriter application) but are modified using TISCI API, correct ?
Do we have to raise VPP to 1.8V when we modify the SWREV-* fields using TISCI API ?

Regards

Walter

4 months ago

0 Hong Guan64 4 months ago

TI__Guru 64235 points

I'd recommend to refer to K3 Security Hardware Architecture TRM
https://dr-download.ti.com/authenticated/secure/software-development/application-software-framework/MD-W5I8h4voaD/09.01.00.05/SPRUIM0C-C-windows-installer.exe?
- "8.1 Booting Keys in EFUSE ROM"
Software Revision Value (96-bit + 96-bit redundancy): SWRV
Config Revision Value (64-bit + 64-bit redundancy): CFGRV
- "8.4 Software Rollback Protection Outline"

Hopefully the sections will help clarifying your questions.
Best,
-Hong

0 Walter Stoll 4 months ago in reply to Hong Guan64

Intellectual 450 points

I know this sections well and they don't answer my questions.

0 Hong Guan64 4 months ago in reply to Walter Stoll

TI__Guru 64235 points

2/. additional reference
https://software-dl.ti.com/tisci/esd/latest/2_tisci_msgs/security/sec_cert_format.html#swrev-footnote
3/. yes, SWRV in the OTP efuse is designed as an option on SW rollback protection on tiboot3.bin in the first stage RoT secure boot.
4/. yes.
5/. it is up to user on how/when to provision SWRV
6/. yes, VPP is required when programming OTP efuse including SWRV
Best,
-Hong

0 Walter Stoll 4 months ago in reply to Hong Guan64

Intellectual 450 points

Answer 2)

https://software-dl.ti.com/tisci/esd/latest/2_tisci_msgs/security/sec_cert_format.html#swrev-footnote reads the following: "tiboot3.bin: ROM will check against the current SWREV value programmed for bootloaders in the device efuses and reject if certificate value is lower than the efuse value".

In order to rollback protect the whole tiboot3.bin image I conclude, that we have to update the eFuse field related to bootloaders which is SWREV-SBL and leave SWREV-BOARDCONFIG, SWREV-SYSFW untouched. Is this correct ?

Answers 5 and 6)

Not sure if I misunderstand something and/or you did not get the point: Up to my understanding, updating (that is modify the value after commissioning) any SWERV-* field is not possible using a OTP keywriter application because this would require the SoC in HS-FS mode (same is true for KEYREV). The only way to modify the fields is to use the TISCI API and e.g. a user space application that calls that API, correct ? If yes, need we raise VPP in that application (note, that I don't talk about the OTP keywriter application) ?

Sorry for insisting. For us these are crucial question about topics we must get done right.

+1 Hong Guan64 4 months ago in reply to Walter Stoll

TI__Guru 64235 points

Walter Stoll said:
In order to rollback protect the whole tiboot3.bin image I conclude, that we have to update the eFuse field related to bootloaders which is SWREV-SBL and leave SWREV-BOARDCONFIG, SWREV-SYSFW untouched. Is this correct ?

yes

Walter Stoll said:
The only way to modify the fields is to use the TISCI API and e.g. a user space application that calls that API, correct ? If yes, need we raise VPP in that application (note, that I don't talk about the OTP keywriter application) ?

yes, yes.

The followoing is on slide #6
https://dr-download.ti.com/authenticated/software-development/application-software-framework/MD-W5I8h4voaD/09.01.00.05/AM62x_OTP_Keywriter_1Q23_v1.pdf?
"NOTE: In-field OTP programming requires software managed option for VPP power.
Required for rollback protection eFuse updates (SWRV) and enabling backup keys (KEY_REVISION)"
Best,
-Hong

Processors

Processors forum

PROCESSOR-SDK-AM64X: AM64x rollback protection