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

Aperta
  • Qualcosa non va?
#128 2 commenti 1 reazione 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Tranquilla
Stack tecnologico
c
Ambito
embedded-iot

Direzione di ricerca

Iniziate esaminando i commit di esempio delle release FSP e gli attuali formati di versione specifici della piattaforma descritti nell’issue. Confrontate gli approcci proposti, inclusi i tag, un formato di versione comune, la denominazione dei binari e i metadati. Il lavoro è completato quando il progetto dispone di un modo concordato e leggibile dalle macchine per associare ogni versione di FSP al relativo binario e al relativo albero dei sorgenti.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
C
Stelle
366
Fork
143
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di intel/FSP

Tutte le issue di intel/FSP

Issue simili

Altre issue su C

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.