FSP version strings are hard to extract and not tied to specific binaries

[philipanda]

The current FSP versioning scheme makes it difficult to identify which binary
corresponds to which version. Recent commit messages show several different
possible version formats:

• Edge Platforms PTL-H PV (3515_56) FSP
  9746b8c
• ASL IPU26.2 v6491_51 3aebe88
• Alder Lake FSP C.1.75.10 95f32b7
• BirchStream FSP (0041D92) 9623d52

Different platforms use different styles. The version sits inside free-form
prose, and there is no git tag or other reference that authoritatively links a
version string to a specific binary.

Several norms and recommendations expect the integrators to provide a clean,
machine-readable version field for each firmware component to be distributed
alongside the firmware, including:

• EU Cyber Resilience Act, Annex I, Part II, point (1)

  Manufacturers of products with digital elements shall:
  (1) identify and document vulnerabilities and components contained
  in products with digital elements, including by drawing up
  a software bill of materials in a commonly used and machine-readable
  format covering at the very least the top-level dependencies
  of the products;

• BSI TR-03183-2

  3.1 Definition of SBOM
  A “Software Bill of Materials” (SBOM) is a machine-processable file containing supply chain relationships
  and details of the components used in a software product. It supports automated processing of information
  on these components.
  (...)
  5.2.2 Required data fields for each component
  (...)
  Component Version:
  (...)
  2. Identifiers according to Semantic Versioning or alternatively
  Calendar Versioning SHOULD be used if one determines the
  versioning scheme; this is often the component creator.

• CISA: 2025 Minimum Elements for a Software Bill of Materials (SBOM
• NIST SP 800-53 control SA-10(5)

A consistent scheme would help integrators to meet these expectations without
writing platform-specific version extraction logic and keep a high quality of
their SBOMs.

Taging each release commit in git in a way so the version string maps to a
specific tree and the binaries it contains, and introducing a common versioning
scheme would be perfect. If not feasible there still exist ways in which the
versioning could be improved:

• Adopt a single version format across platforms (SemVer/CalVer?)
• Include the version string in the binary names in a structured way
• Add a structured field in commit message, or a small machine-readable metadata
  file next to the binary

Improving the FSP versioning flow would allow firmware integrators for a better
compliance with the security regulations and make the SBOMs more clean,
reliable, and attestable. Using a common and well-known versioning scheme across
the FSP releases would allow the parties interested in the SBOM to better
understand whether a given firmware contains the newest version and whether it
contains known vulnerabilities.

[nate-desimone]

Hi @philipanda, the FSP specification defines a mechanism for embedding the FSP version number into the FSP binary itself. It is detailed in §5.1 of the FSP specification. Please see following excerpts from the specification:

Byte Offset	Size in Bytes	Field	Description
12	4	ImageRevision	Revision of the FSP binary. Major.Minor.Revision.Build If FSP HeaderRevision is <= 5, the ImageRevision can be decoded as follows: 7 : 0 - Build Number 15 : 8 - Revision 23 : 16 - Minor Version 31 : 24 - Major Version If FSP HeaderRevision is >= 6, ImageRevision specifies the low-order bytes of the build number and revision while ExtendedImageRevision specifies the high- order bytes of the build number and revision. 7 : 0 - Low Byte of Build Number 15 : 8 - Low Byte of Revision 23 : 16 - Minor Version 31 : 24 - Major Version
76	2	ExtendedImageRevision	This value is only valid if FSP HeaderRevision is >= 6. ExtendedImageRevision specifies the high- order byte of the revision and build number in the FSP binary revision. 7 : 0 - High Byte of Build Number 15 : 8 - High Byte of Revision The FSP binary build number can be decoded as follows: Build Number = ExtendedImageRevision[7:0] << 8) | ImageRevision[7:0] Revision = (ExtendedImageRevision[15:8] << 8) | ImageRevision[15:8] Minor Version = ImageRevision[23:16] Major Version = ImageRevision[31:24]

All FSP binaries have their version numbers embedded this way. This version number should be considered as the canonical version number. Here is an example of using the SplitFspBin.py tool in this repository to read the version number:

$ SplitFspBin.py info -f ../RaptorLakeFspBinPkg/Client/RaptorLakeP/Fsp.fd
<snip>
FSP_S contains FV0
<FSP_INFORMATION_HEADER>:
  Signature                  = 0x48505346 ('FSPH')
  HeaderLength               = 0x00000050
  Reserved1                  = 0x0000
  SpecVersion                = 0x23
  HeaderRevision             = 0x06
  ImageRevision              = 0x0C01C850
<snip>
  ExtendedImageRevision      = 0x0000 ('0C.01.00C8.0050')
<snip>

I believe this should address your issue, please let me know.

[swong23]

Appreciate for all the feedback. Moving forward the nomenclature (of FSP of Edge platforms) will be standardized as such (in the commit msg):

• e.g.: Edge Platforms RPL-S MR2 (4445_02) FSP ver C.0.CB.20

Where:

• Edge Platforms: Platform differentiator – to be distinguished from Client platforms.
• RPL-S: Product code name
• MR2: Release milestone
• (4445_02): Corresponding BIOS revision
• FSP ver C.0.CB.20 : FSP version as shown in FSP binary description (read from BCT, binary config tool).

Thanks!