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

未关闭
  • 哪里不对？
#128 2 条评论 1 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
35/100
Issue 类型
功能
描述清晰度
需要澄清
活跃度
冷清
技术栈
c
领域
embedded-iot

调研方向

首先查看示例 FSP 发布提交以及 issue 中描述的当前平台特定版本格式。比较提出的方案，包括 tags、统一的版本格式、二进制文件命名和元数据。当项目拥有一种约定一致且机器可读的方式，将每个 FSP 版本映射到其特定的二进制文件和源代码树时，即表示完成。

由索引模型根据 Issue 内容生成。

描述

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
    9746b8c492d9c06882ee55ae29d86d8f65205f2d
  • ASL IPU26.2 v6491_51 3aebe88923ecbb639ad95abaebe29cb190ddec57
  • Alder Lake FSP C.1.75.10 95f32b770cddc3df401a29828a479bd74370de38
  • BirchStream FSP (0041D92) 9623d524500c140a6b11d2c727cb282b54962f09

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.

主要语言
C
星标
366
派生
143
30 天内没有已合并 PR

环境准备

  • 没有 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 阅读贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

intel/FSP 的其他 Issue

查看 intel/FSP 的全部 Issue

相似的 Issue

更多 C Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。