attestation: make platform metadata best-effort for azure evidence - #2
Open
samlaf wants to merge 1 commit into
Open
attestation: make platform metadata best-effort for azure evidence#2samlaf 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 disk count holds to what platform::metadata_for would have returned: one named list of virtual device prefixes, the same set is_virtual_block_device excludes, and the Azure resource disk subtracted the way metadata_for subtracts it. A LUKS node carries dm-* devices, so a filter blind to those would over-count on exactly the machines this fallback exists for. The proper home for all of this is attest-measure's platform::metadata_for, where a /proc/meminfo fallback 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
force-pushed
the
azure-platform-metadata-fallback
branch
from
August 19, 2026 14:45
4335649 to
2ce0fee
Compare
samlaf
added a commit
to SeismicSystems/enclave
that referenced
this pull request
Aug 19, 2026
flashbots/attested-tls#78 — portable azure vTPM quote verification and the azure-attester/azure-verifier feature split — merged upstream, so the fork rebases onto upstream main and the pin follows it to SeismicSystems/attested-tls#2. The fork stays a single commit ahead of upstream, which is what keeps it cheap to drop once its patch lands there. The new base carries three upstream changes with it: - dcap-qvl resolves from crates.io 0.5.2 rather than a Phala git rev. - attest moves to 8206cd1, which also excludes dm-* and md* devices when counting disks; the fork's azure fallback follows the same filter, so a LUKS node is not over-counted. - pccs reports a missing rustls crypto provider instead of panicking. attestation-service installs aws-lc-rs at startup, so this repo never hit that panic and nothing here changes. Cargo.lock moves with the pin.
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.
Using this PR for now but should eventually upstream this.
Created an issue upstream for this: Easy-TEE/attest#24
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.
The disk count holds to what platform::metadata_for would have returned:
one named list of virtual device prefixes, the same set
is_virtual_block_device excludes, and the Azure resource disk subtracted
the way metadata_for subtracts it. A LUKS node carries dm-* devices, so a
filter blind to those would over-count on exactly the machines this
fallback exists for.
The proper home for all of this is attest-measure's
platform::metadata_for, where a /proc/meminfo fallback 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.