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

オープン
  • 何か問題がありますか？
#128 コメント 2 件 リアクション 1 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
35/100
issue の種類
機能追加
明瞭さ
説明が足りない
活発さ
静か
技術スタック
c
領域
embedded-iot

調査の方向性

まず、FSP のリリース例のコミットと、issue に記載されている現在のプラットフォーム固有のバージョン形式を確認します。タグ、共通のバージョン形式、バイナリの命名、メタデータなど、提案されているアプローチを比較します。各 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 はありません

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

intel/FSP のほかの issue

intel/FSP の issue をすべて見る

似ている issue

C の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。