OpenDevicePartnership / OpenDevicePartnership/odp-platform-common

OEM Adoption Materials

Open
#114 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Rust
Stars
1
Forks
5
Avg merge
3d 4h
Merged PRs (30d)
9

Description

Parent roadmap: #190

Goal

Package the evidence needed for an OEM architecture decision on Patina + patina_boot.

Deliverables

  • OEM adoption deck focused on architecture, bug prevention, testability, and measured performance
  • Patina upstream proposal separating generic mechanism from platform policy
  • threat model and security claim boundary
  • links to semantic parity, fuzzing, Secure Boot matrix, matched-policy A/B, QEMU, and platform-neutrality evidence
  • migration checklist and acceptance gates for an OEM pilot

Dependencies

  • #191 fail-closed security transition
  • #192 boot-source hardening
  • #193 differential fuzzing
  • #194 Secure Boot matrix
  • #196 semantic parity matrix
  • #195 matched-policy A/B
  • #118 QEMU + OVMF reference consumer
  • #158 platform-neutral vendor reuse
  • #183 benchmark presentation

Acceptance criteria

  • every security and performance claim links to reproducible evidence
  • unsupported claims are explicitly excluded
  • upstream and OEM asks are separate
  • pilot entry/exit criteria are documented

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reviewing the parent roadmap #190 and the dependency issues #191-#196, #118, #158, and #183 to gather the referenced security, fuzzing, Secure Boot, parity, QEMU, platform-neutrality, and benchmark evidence. Done means an OEM adoption deck, separated upstream and OEM asks, a threat-model boundary, migration checklist, and pilot entry/exit criteria with reproducible links and unsupported claims excluded.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
documentation, performance, security
Issue type
Documentation
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.