microsoft / microsoft/secureboot_objects
High Confidence classification ignores measured-boot log overflow on EOSL OEM firmware
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 289
- Forks
- 89
- Avg merge
- 3d 10h
- Merged PRs (30d)
- 7
Description
Device bucket a76a9c670a8c139d3d783551a435fd5c4948f898d8acc23f9a05a65c1db5021d stayed High Confidence after Windows successfully wrote the 2023 db certificates.
On Dell Inspiron 5559 BIOS 1.9.0 that write grew db from 3,143 to 7,636 bytes. Combined with a current dbx (~23 KB), the firmware TCG log exceeded a ~32 KiB buffer. Logging stopped; PCR extension continued. BitLocker then failed with FVE_E_NO_TPM_BIOS / Event 813 / Event 1796.
High Confidence here means “the variable write succeeded,” which is exactly what destroyed measured boot.
Evidence: https://github.com/Sizzlechest/inspiron-5559-tcg-log-overflow
Ask: treat PCR7 bindability / log completeness as a classification input for EOSL firmware, or document these platforms as not supported for full dbx deployment.
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 by reviewing the linked inspiron-5559-tcg-log-overflow evidence and the classification behavior described in this issue; no repository file or test is identified. Done means either PCR7 bindability and log completeness affect EOSL firmware classification, or the affected platforms are explicitly documented as unsupported for full dbx deployment.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- operating-systems, security
- Issue type
- Bug
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100