Deprecate FMC SVN #1703
Assignees
Labels
Caliptra v2.0
Items to be considered for v2.0 Release
Comments
bluegate010
added a commit
to bluegate010/caliptra-sw
that referenced
this issue
Nov 5, 2024
Apologies for the size of this PR. With this change, there is now a singular SVN representing the security state of both FMC and Runtime. This is done as part of enabling Stable Identity in ROM, which can only easily be implemented in terms of a single SVN. As part of this deprecation, the duties of tracking min-SVN have been moved from FMC to ROM. This is a prelude to having ROM compute the Stable Identity chain based on the firmware's singular SVN. This does not alter the external API for Caliptra, with the sole exception that what was previously reported as the FMC's SVN is now the value of the (FMC+RT) FW SVN as it was during cold-boot. - The FMC and Runtime images still each carry an SVN, but this is done only for backwards compatibility in the build tooling, and ROM ensures the two SVNs are equal. - The FMC and Runtime alias certificates still each carry an SVN. - The FMC alias certificate's SVN is the value that the firmware's SVN was at cold-boot. - The Runtime alias certificate's SVN is the value that the firmware's SVN was at the last update-reset. See additional commentary in chipsalliance#1703.
bluegate010
added a commit
to bluegate010/caliptra-sw
that referenced
this issue
Nov 7, 2024
Apologies for the size of this PR. With this change, there is now a singular SVN representing the security state of both FMC and Runtime. This is done as part of enabling Stable Identity in ROM, which can only easily be implemented in terms of a single SVN. As part of this deprecation, the duties of tracking min-SVN have been moved from FMC to ROM. This is a prelude to having ROM compute the Stable Identity chain based on the firmware's singular SVN. This does not alter the external API for Caliptra, with the sole exception that what was previously reported as the FMC's SVN is now the value of the (FMC+RT) FW SVN as it was during cold-boot. - The FMC and Runtime images still each carry an SVN, but this is done only for backwards compatibility in the build tooling, and ROM ensures the two SVNs are equal. - The FMC and Runtime alias certificates still each carry an SVN. - The FMC alias certificate's SVN is the value that the firmware's SVN was at cold-boot. - The Runtime alias certificate's SVN is the value that the firmware's SVN was at the last update-reset. See additional commentary in chipsalliance#1703.
bluegate010
added a commit
to bluegate010/caliptra-sw
that referenced
this issue
Nov 7, 2024
Apologies for the size of this PR. With this change, there is now a singular SVN representing the security state of both FMC and Runtime. This is done as part of enabling Stable Identity in ROM, which can only easily be implemented in terms of a single SVN. As part of this deprecation, the duties of tracking min-SVN have been moved from FMC to ROM. This is a prelude to having ROM compute the Stable Identity chain based on the firmware's singular SVN. This does not alter the external API for Caliptra, with the sole exception that what was previously reported as the FMC's SVN is now the value of the (FMC+RT) FW SVN as it was during cold-boot. - The FMC and Runtime images still each carry an SVN, but this is done only for backwards compatibility in the build tooling, and ROM ensures the two SVNs are equal. - The FMC and Runtime alias certificates still each carry an SVN. - The FMC alias certificate's SVN is the value that the firmware's SVN was at cold-boot. - The Runtime alias certificate's SVN is the value that the firmware's SVN was at the last update-reset. See additional commentary in chipsalliance#1703.
bluegate010
added a commit
to bluegate010/caliptra-sw
that referenced
this issue
Nov 11, 2024
Apologies for the size of this PR. With this change, there is now a singular SVN representing the security state of both FMC and Runtime. This is done as part of enabling Stable Identity in ROM, which can only easily be implemented in terms of a single SVN. As part of this deprecation, the duties of tracking min-SVN have been moved from FMC to ROM. This is a prelude to having ROM compute the Stable Identity chain based on the firmware's singular SVN. This does not alter the external API for Caliptra, with the sole exception that what was previously reported as the FMC's SVN is now the value of the (FMC+RT) FW SVN as it was during cold-boot. - The FMC and Runtime images still each carry an SVN, but this is done only for backwards compatibility in the build tooling, and ROM ensures the two SVNs are equal. - The FMC and Runtime alias certificates still each carry an SVN. - The FMC alias certificate's SVN is the value that the firmware's SVN was at cold-boot. - The Runtime alias certificate's SVN is the value that the firmware's SVN was at the last update-reset. See additional commentary in chipsalliance#1703.
bluegate010
added a commit
to bluegate010/caliptra-sw
that referenced
this issue
Nov 11, 2024
Apologies for the size of this PR. With this change, there is now a singular SVN representing the security state of both FMC and Runtime. This is done as part of enabling Stable Identity in ROM, which can only easily be implemented in terms of a single SVN. This does not alter the external API for Caliptra, with the sole exception that what was previously reported as the FMC's SVN is now the value of the (FMC+RT) FW SVN as it was during cold-boot. - The FMC and Runtime images still each carry an SVN, but this is done only for backwards compatibility in the build tooling, and ROM ensures the two SVNs are equal. - The FMC and Runtime alias certificates still each carry an SVN. - The FMC alias certificate's SVN is the value that the firmware's SVN was at cold-boot. - The Runtime alias certificate's SVN is the value that the firmware's SVN was at the last update-reset. See additional commentary in chipsalliance#1703.
bluegate010
added a commit
to bluegate010/caliptra-sw
that referenced
this issue
Nov 12, 2024
Apologies for the size of this PR. With this change, there is now a singular SVN representing the security state of both FMC and Runtime. This is done as part of enabling Stable Identity in ROM, which can only easily be implemented in terms of a single SVN. This does not alter the external API for Caliptra, with the sole exception that what was previously reported as the FMC's SVN is now the value of the (FMC+RT) FW SVN as it was during cold-boot. - The FMC and Runtime images still each carry an SVN, but this is done only for backwards compatibility in the build tooling, and ROM ensures the two SVNs are equal. - The FMC and Runtime alias certificates still each carry an SVN. - The FMC alias certificate's SVN is the value that the firmware's SVN was at cold-boot. - The Runtime alias certificate's SVN is the value that the firmware's SVN was at the last update-reset. See additional commentary in chipsalliance#1703.
bluegate010
added a commit
to bluegate010/caliptra-sw
that referenced
this issue
Nov 12, 2024
Apologies for the size of this PR. With this change, there is now a singular SVN representing the security state of both FMC and Runtime. This is done as part of enabling Stable Identity in ROM, which can only easily be implemented in terms of a single SVN. This does not alter the external API for Caliptra, with the sole exception that what was previously reported as the FMC's SVN is now the value of the (FMC+RT) FW SVN as it was during cold-boot. - The FMC and Runtime images still each carry an SVN, but this is done only for backwards compatibility in the build tooling, and ROM ensures the two SVNs are equal. - The FMC and Runtime alias certificates still each carry an SVN. - The FMC alias certificate's SVN is the value that the firmware's SVN was at cold-boot. - The Runtime alias certificate's SVN is the value that the firmware's SVN was at the last update-reset. See additional commentary in chipsalliance#1703.
bluegate010
added a commit
to bluegate010/caliptra-sw
that referenced
this issue
Nov 13, 2024
Apologies for the size of this PR. With this change, there is now a singular SVN representing the security state of both FMC and Runtime. This is done as part of enabling Stable Identity in ROM, which can only easily be implemented in terms of a single SVN. This does not alter the external API for Caliptra, with the sole exception that what was previously reported as the FMC's SVN is now the value of the (FMC+RT) FW SVN as it was during cold-boot. - Build tooling leaves the FMC image TOC entry's SVN field as zero. ROM only looks at the RT FW TOC entry's SVN field. - The FMC and Runtime alias certificates still each carry an SVN. - The FMC alias certificate's SVN is the value that the firmware's SVN was at cold-boot. - The Runtime alias certificate's SVN is the value that the firmware's SVN was at the last update-reset. See additional commentary in chipsalliance#1703.
bluegate010
added a commit
to bluegate010/caliptra-sw
that referenced
this issue
Nov 14, 2024
Apologies for the size of this PR. With this change, there is now a singular SVN representing the security state of both FMC and Runtime. This is done as part of enabling Stable Identity in ROM, which can only easily be implemented in terms of a single SVN. This does not alter the external API for Caliptra, with the sole exception that what was previously reported as the FMC's SVN is now the value of the (FMC+RT) FW SVN as it was during cold-boot. - Build tooling leaves the FMC image TOC entry's SVN field as zero. ROM only looks at the RT FW TOC entry's SVN field. - The FMC and Runtime alias certificates still each carry an SVN. - The FMC alias certificate's SVN is the value that the firmware's SVN was at cold-boot. - The Runtime alias certificate's SVN is the value that the firmware's SVN was at the last update-reset. See additional commentary in chipsalliance#1703.
bluegate010
added a commit
to bluegate010/caliptra-sw
that referenced
this issue
Nov 17, 2024
Apologies for the size of this PR. With this change, there is now a singular SVN representing the security state of both FMC and Runtime. This is done as part of enabling Stable Identity in ROM, which can only easily be implemented in terms of a single SVN. This does not alter the external API for Caliptra, with the sole exception that what was previously reported as the FMC's SVN is now the value of the (FMC+RT) FW SVN as it was during cold-boot. - Build tooling leaves the FMC image TOC entry's SVN field as zero. ROM only looks at the RT FW TOC entry's SVN field. - The FMC and Runtime alias certificates still each carry an SVN. - The FMC alias certificate's SVN is the value that the firmware's SVN was at cold-boot. - The Runtime alias certificate's SVN is the value that the firmware's SVN was at the last update-reset. See additional commentary in chipsalliance#1703.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Firmware is tagged with two SVNs: FMC SVN and RT SVN. I don't think we need both.
FMC and RT FW is monolithically signed, and monolithically runtime-updated[1]. It can also be monolithically associated with an SVN.
For backwards compatibility, we could continue to add an SVN to the FMC alias key. But we can make that SVN equal the SVN in the RT FW alias key.
Without distinct SVNs, we would expect that a vulnerability in either FMC or RT FW would motivate an increment of the singular SVN that describes them both.
This will also be important in allowing ROM to implement a hash chain to support stable identity features. ROM can only generate a hash chain from a single-dimensional SVN. If there are two SVNs, stable identity will need to ignore one of the SVNs.
[1] While FMC cannot be runtime-updated, Caliptra enforces that the FMC in the new bundle equals the FMC in the current bundle. Therefore, when an (FMC, RT FW) pair is signed and associated with an SVN, the reported SVN will describe the current FMC and RT FW. In other words, Caliptra does not allow drift or disassociation between monolithically-signed FMC/RT FW images.
The text was updated successfully, but these errors were encountered: