attestation: make platform metadata best-effort for azure evidence - #1
Draft
samlaf wants to merge 1 commit into
Draft
attestation: make platform metadata best-effort for azure evidence#1samlaf wants to merge 1 commit into
samlaf wants to merge 1 commit into
Conversation
Azure marketplace kernels (linux-azure, linux-azure-fde) do not ship CONFIG_DMI_SYSFS, and where dmi-sysfs does exist its raw entries are readable only by root, so azure evidence generation on a stock Azure CVM fails with "Cannot retrieve platform metadata: I/O: No such file or directory". No verifier consults ram_bytes/num_disks for azure evidence — they exist for the portable image-hash policies on DCAP/GCP platforms — so collect them best-effort: use SMBIOS when available, otherwise fall back to /proc/meminfo for RAM and a /sys/block count for disks. The proper home for this fallback is attest-measure's platform::metadata_for, where it would cover every platform and caller; a TODO marks the added block for deletion once that lands in easy-tee/attest and the attest pin picks it up.
samlaf
marked this pull request as draft
August 7, 2026 19:47
samlaf
added a commit
to SeismicSystems/enclave
that referenced
this pull request
Aug 7, 2026
Point the `attestation` backend at SeismicSystems/attested-tls, pinned at 4fb3f4e (azure-verifier-portability plus the platform-metadata fallback, SeismicSystems/attested-tls#1). The comment in Cargo.toml tracks switching back once the upstream PR lands (flashbots/attested-tls#78). The fork splits upstream's Linux-only `azure` feature in two: - `azure-verifier`: Azure evidence verification, pure computation over the evidence bytes. Enabled on all platforms, so verify-quote now builds and runs natively on macOS — its module doc and --help drop the run-in-a-Linux-container guidance. - `azure-attester` (implies azure-verifier): evidence generation via the vTPM/TPM quote path, still Linux-only. Enabled in the existing Linux-target dependency block. The fork also makes platform-metadata collection best-effort for Azure evidence generation. Stock Azure marketplace kernels lack CONFIG_DMI_SYSFS, which made generation fail with "Cannot retrieve platform metadata" at the previous commit; this is what turns the attestation_service_tdx_tests CI job green again.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Based on top of flashbots#78, which will hopefully be merged upstream first.
The proper home for this fallback is attest-measure's platform::metadata_for, where it would cover every platform and caller; a TODO marks the added block for deletion once that lands in easy-tee/attest and the attest pin picks it up. This PR is just a temporary fix so that I can test it and make sure it works.
Description
Azure marketplace kernels (linux-azure, linux-azure-fde) do not ship CONFIG_DMI_SYSFS, and where dmi-sysfs does exist its raw entries are readable only by root, so azure evidence generation on a stock Azure CVM fails with "Cannot retrieve platform metadata: I/O: No such file or directory".
No verifier consults ram_bytes/num_disks for azure evidence — they exist for the portable image-hash policies on DCAP/GCP platforms — so collect them best-effort: use SMBIOS when available, otherwise fall back to /proc/meminfo for RAM and a /sys/block count for disks.