Certificate Format Updates

[amd-aliem]

Adds host and guest environment detection to certification reports so results include the exact software versions used during the run.

• All detection is best-effort - failures produce None, never errors.
• Guest OS detection happens lazily on first successful VM launch, then is cached in the environment dict.
• The environment dict is threaded through existing call chains rather than stored as global state.
• guest kernel reporting to be added in a follow-up PR.

Example Certification Formatting

Achieved Certification Level 3.0.0-1

Certified level: 3.0.0-1
Started: 2026-06-30T23:04:58.182398+00:00
Completed: 2026-06-30T23:05:13.829545+00:00

Environment

• Host OS: Ubuntu 25.04
• Host kernel: 6.14.0-37-generic
• Guest OS: Ubuntu 26.04 LTS
• QEMU: 9.2.1 (Debian 1:9.2.1+ds-1ubuntu5.2)
• OVMF: 2025.02-3ubuntu2.2 (ovmf)

Level 3.0.0-0

Test	Scope	Result
attestation-test	mixed	✅

Level 3.0.0-1

Test	Scope	Result
snphost-config-commit	host	✅

[Copilot]

Pull request overview

This PR extends the certification reporting pipeline to capture and emit host/guest environment details (OS/kernel/QEMU/OVMF) so certification results record the software context used during a run.

Changes:

• Added host environment detection (OS, kernel, QEMU, OVMF) and plumbed an environment dict through CLI execution and report writers.
• Added guest OS detection via vsock and updates the shared environment dict after a successful VM launch.
• Updated Markdown/JSON outputs to include the detected environment metadata, and refactored OVMF path discovery into a helper.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
sev_verify/vm_profile.py	Adds find_ovmf_path() helper and reuses it when resolving OVMF firmware.
sev_verify/output.py	Adds environment support to JSON/Markdown writers and renders an “Environment” section in Markdown.
sev_verify/os_info.py	Introduces host /etc/os-release parsing and guest OS detection via vsock; updates the environment dict.
sev_verify/environment.py	Implements best-effort host component/version detection (QEMU, kernel, OVMF, OS).
sev_verify/cli.py	Wires environment detection into CLI flow; updates environment with guest OS after VM launches; passes environment into outputs.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated 3 comments.

[Copilot]

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated 3 comments.

[benland72]

• All detection is best-effort - failures produce None, never errors.

Quick question(s):

1. Will there be documentation updates to reflect that subtlety about detection being best effort with the possibility of seeing "None" ?
2. Does a green check mark for a mixed scope test imply that it passed on both host and guest?

[amd-aliem]

Quick question(s):

1. Will there be documentation updates to reflect that subtlety about detection being best effort with the possibility of seeing "None" ?

• Yes we can add a section to the Certifications page to call this out - it's likely a small bug if None shows up, the 'best effort' is to still allow the certificate to be pushed and published instead of erroring out, as the env section is informational.

2. Does a green check mark for a mixed scope test imply that it passed on both host and guest?

• Yes, failing any of the steps will result in a fail for the whole test.

[DGonzalezVillal]

I personally like when I can also see the steps run for each test as part of the certification, just to get an idea of what's happening on each test. Do you guys think that makes the certificate too clustered?. That way also people don't necessarily need to see the source code of each test to see what's going on. I do like the additions of the environment.

Also for different cert generations, do you guys think we will generate different certificates? a cert for 3.0.0, one for 3.1.0 and one for 4.0.0?

[amd-aliem]

I personally like when I can also see the steps run for each test as part of the certification, just to get an idea of what's happening on each test. Do you guys think that makes the certificate too clustered?. That way also people don't necessarily need to see the source code of each test to see what's going on. I do like the additions of the environment.

Agree, this will be added as a part of the PR that's currently in draft - it appends the steps after this part and you'll see it in the GH issue - see amd-aliem#187 for an example.

Also for different cert generations, do you guys think we will generate different certificates? a cert for 3.0.0, one for 3.1.0 and one for 4.0.0?

Agree that each manifest should have its own certificate (so we'll have one GH issue per HW generation set).