OpenDevicePartnership / OpenDevicePartnership/odp-platform-common
Differentially fuzz EFI load options and device paths
Open
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 1
- Forks
- 5
- Avg merge
- 3d 4h
- Merged PRs (30d)
- 9
Description
Parent: #190
Goal
Produce evidence that malformed NVRAM and device-path inputs are rejected safely and consistently.
Scope
- build a corpus for BootOrder, Boot####, EFI_LOAD_OPTION, and device-path nodes
- fuzz Rust parsing and EDK2 BmValidateOption/equivalent parsing with identical inputs
- use sanitizers for C and coverage-guided fuzzing for Rust
- retain every behavioral mismatch as a regression test
Acceptance criteria
- no crash, out-of-bounds access, hang, or sanitizer finding in the agreed run budget
- malformed-input rejection behavior is documented
- differential mismatches are resolved or explicitly justified
- corpus and reproducible commands run in CI
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with parent #190 and the Rust parsing and EDK2 BmValidateOption/equivalent parsing entry points named here; determine how identical EFI_LOAD_OPTION and device-path inputs reach both implementations. Define the agreed run budget and CI commands, then verify completion through sanitizer and coverage runs, documented rejection behavior, and retained differential mismatches as regression tests.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- c, rust
- Domain
- ci-cd, operating-systems, security, testing-qa
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 30/100