Forward compatibility

[cschramm]

In a remote attestation use case, a client needs to parse attestation reports provided by a server. The sev crate currently does not seem like a good fit for that, as it is not forward compatible.

For example, an existing client fails to parse a V5 report provided by a server if it has not received #312 yet. This seems rather unnecessary and the client could easily provide forward compatibility as long as new attestation versions do not actually break previous specs.

The reason that the parser fails is simply because skip_bytes expects all reserved areas to be zeroed. The spec does not even require that for all reserved areas. It seems like the only reason for the parser to expect it is that when a parsed AttestationReport gets encoded to bytes, reserved areas also simply get filled with zeros.

Would you consider actually reading and writing contents of reserved areas instead of requiring them to be zeroed to provide simple forward compatibility for distributed software?

[DGonzalezVillal]

@tylerfanelli @larrydewey

He raises a good point. In our original discussion, we noted that this breaks a trust boundary. Forward compatibility is tricky—while we could ignore bytes that are supposed to be 0s and parse, for example, a v6 report as a v5, the displayed information would then be incomplete or misleading. We had talked about preparing the crate to handle new reports more gracefully, but this also depends on users updating their crates quickly to avoid breakages.

This particular fix is straightforward, but I wanted to check whether there are any reasons we would still want to fail when parsing bytes that should be 0s in newer report versions.

[cschramm]

Kind ping @tylerfanelli @larrydewey @DGonzalezVillal

We have the need to decide whether to stick to the crate's report parser or use our own to provide such forward compatibility. It would be very helpful to know whether you'd be open to supporting that requirement.

[DGonzalezVillal]

Hey @cschramm,

Apologies — it seems @tylerfanelli hasn’t had a chance to take a look yet, so we haven’t been able to discuss this.

I wanted to bring up another point about forward compatibility that you might want to weigh in on.

The truth is, even if we remove the skip_bytes check, we’d still be in a situation where we aren’t reporting the full content of the reports.

What I mean is that if we don’t have field parsing for new entries and simply ignore those fields when parsing, the user would end up seeing an incomplete report.

We might say, “this is a v5 report,” when in reality it’s a v6 report. The report would likely still pass certificate verification, but the user wouldn’t actually see the full contents of the newer report.

Is that a trade-off you’re comfortable with?

The alternative would be for us to focus on being better prepared for new attestation report releases and aim for day-one support when new versions come out, to avoid future breakages.

Just checking in to get your thoughts.

[cschramm]

Here is our situation:

We have services running on servers that we control and we provide customers with libraries that they integrate into their software (all kinds of; web, mobile, desktop). The libraries establish an "attested channel" to the servers, i.e., they receive an attestation report from them, parse it and apply certain checks such as ALIAS_CHECK_COMPLETE, a minimal CommitedVersion, and certain minimals for the CommitedTcb.

When issues like AMD-SB-3011, AMD-SB-3015, AMD-SB-3017, AMD-SB-3020, AMD-SB-7029, AMD-SB-7033 etc. arise, we update the servers and adapt the checks in the libraries accordingly. Of course, we keep the sev crate up to date and publish new library versions. However, the servers have to support older client versions as well as especially for desktop software updates might reach end users very slowly. Those older versions will not apply the most recent checks and thus do not enforce the same guarantees, of course, but they should still work.

Here comes new report versions: A certain firmware update brought us V5. Even if we assume that explicit support is in sev for a while already and we have published library versions with it, applying the firmware update to the servers means breaking all older client versions just due to the skip_bytes check. At the same time, we have to update the servers to apply mitigations and adapt checks in new library versions to verify that.

What I mean is that if we don’t have field parsing for new entries and simply ignore those fields when parsing, the user would end up seeing an incomplete report.

We might say, “this is a v5 report,” when in reality it’s a v6 report. The report would likely still pass certificate verification, but the user wouldn’t actually see the full contents of the newer report.

Is that a trade-off you’re comfortable with?

Absolutely. Old versions of our libraries are fine with that, as they do not know about new fields anyway and do not apply any checks on them. Regarding the end user, one can always provide the complete binary attestation report, not the parsed one.

The alternative would be for us to focus on being better prepared for new attestation report releases and aim for day-one support when new versions come out, to avoid future breakages.

Day one is too late. 😉

[larrydewey]

Here is our situation:

We have services running on servers that we control and we provide customers with libraries that they integrate into their software (all kinds of; web, mobile, desktop). The libraries establish an "attested channel" to the servers, i.e., they receive an attestation report from them, parse it and apply certain checks such as ALIAS_CHECK_COMPLETE, a minimal CommitedVersion, and certain minimals for the CommitedTcb.

When issues like AMD-SB-3011, AMD-SB-3015, AMD-SB-3017, AMD-SB-3020, AMD-SB-7029, AMD-SB-7033 etc. arise, we update the servers and adapt the checks in the libraries accordingly. Of course, we keep the sev crate up to date and publish new library versions. However, the servers have to support older client versions as well as especially for desktop software updates might reach end users very slowly. Those older versions will not apply the most recent checks and thus do not enforce the same guarantees, of course, but they should still work.

Here comes new report versions: A certain firmware update brought us V5. Even if we assume that explicit support is in sev for a while already and we have published library versions with it, applying the firmware update to the servers means breaking all older client versions just due to the skip_bytes check. At the same time, we have to update the servers to apply mitigations and adapt checks in new library versions to verify that.

What I mean is that if we don’t have field parsing for new entries and simply ignore those fields when parsing, the user would end up seeing an incomplete report.
We might say, “this is a v5 report,” when in reality it’s a v6 report. The report would likely still pass certificate verification, but the user wouldn’t actually see the full contents of the newer report.
Is that a trade-off you’re comfortable with?

Absolutely. Old versions of our libraries are fine with that, as they do not know about new fields anyway and do not apply any checks on them. Regarding the end user, one can always provide the complete binary attestation report, not the parsed one.

The alternative would be for us to focus on being better prepared for new attestation report releases and aim for day-one support when new versions come out, to avoid future breakages.

Day one is too late. 😉

I think this is an incredibly important point to clarify. In order to honestly verify the attestation claims coming from the firmware, the claims must match an expected cryptographic measurement. The skip_bytes check was originally added to guarantee that a roll-back attack against verification would be impossible, and to not only stop users from proceeding, but to raise a giant red flag. Even if VirTEE were to program in a bypass of the skip_bytes functionality, attempting to verify a v6 report as a v5 report will mathematically fail, as the underlying bytes used to generate the cryptographic measurement will not match.

[cschramm]

Even if VirTEE were to program in a bypass of the skip_bytes functionality, attempting to verify a v6 report as a v5 report will mathematically fail, as the underlying bytes used to generate the cryptographic measurement will not match.

Fair point. We are only using the parsed AttestationReport struct, but not the Verifiable trait. We simply check the signature for the raw 0x2a0 bytes (the original ones that we parsed as AttestationReport, not some binary representation built from the parsed report).

However, my proposal is to handle reserved areas both when decoding and encoding. AttestationReport's Encoder would not write zeroes, but instead just write whatever the Decoder read. The to_bytes method used to get the raw report for verification should then restore exactly what from_bytes received.

The skip_bytes check was originally added to guarantee that a roll-back attack against verification would be impossible

Not sure if I get that, to be honest.

A completely different perspective on the check: Is it actually correct to assume that the reserved bytes are zero? While the reserved area before REPORT_DATA is defined to be zero, the ones before CHIP_ID, COMMITTED_BUILD, LAUNCH_TCB, and SIGNATURE are not. I might be missing something, but to me, the specification suggests that the firmware could return non-zero junk there. The check would be plain wrong then and verification could not work as the Encoder writes wrong values.

[DGonzalezVillal]

Hello @cschramm — apologies for the long delay; I was tied up with other projects. I’ve been thinking about this and discussing it internally to find a good solution.

As I understand it, the VirTEE library acts as a relying party. We provide APIs that simplify creating attestation requests and parsing responses so users can verify and interact with the attestation report.

Currently, we support parsing up to report version 5. If a new version (say v6) introduces a new field X, ignoring X could cause us to overstate security. That’s acceptable only if X represents a strictly additive security improvement. But if X can indicate a vulnerability or any potential degradation in security posture, we must not ignore it. The challenge is we don’t know which case applies until the new spec is published—so we can’t make assumptions in advance.

Given that, I see two options:

a) Expose the raw report

Add a method to fetch the raw binary attestation report from the firmware.
The library will attempt verification and parsing. If the report version isn’t supported yet, we return an “unsupported version” error for the structured parse. Users who still need to inspect it can parse the raw bytes themselves (at their own risk) until library support is added.
b) Provide a best-effort parse that is never treated as verified

Offer an optional parsing path that returns a view of fields even if reserved bytes are non-zero or the version is newer.
Mark this output as invalid/dirty and explicitly non-verifiable; it’s for diagnostics/telemetry only, not for security decisions.
I’m hesitant about this approach because it introduces a concept not present in the spec and risks confusion. If we do it, we should use a separate “view” type (not the verified AttestationReport type) to avoid accidental misuse.

For your use case, option (a)—exposing the raw bytes—seems more desirable. It keeps the verified path fail-closed while still giving you access to the evidence.

On reserved fields: you can assume they are zero in supported versions. We enforce “must be zero” on reserved ranges (most are explicitly labeled MBZ). If a new report version uses those bytes, our strict parser will reject it until we add support. This is intentional to avoid overstating security in older clients.

[cschramm]

Thank you for that explanation. I do get your point.

Option (a) is not what we need. We are not interacting with firmware on the distributed clients. The clients get a recent attestation report from a server, which they want to parse and verify certain details. Option (b) would be what they need as that is exactly what they use the sev crate for: a parser that returns a view on the raw attestation report. It is obvious that if they are not up to date, they cannot have the desired security guarantees. This not only applies to new fields in new versions of the attestation report, but also, e.g., to situations where we raised the minimum CommitedTcb on recent clients - older clients will still apply the lower minimum known to them. However, it would be nice if they did not just break completely on server firmware updates.

I think option (b) could be a feature flag, say encoders, that guards

• the zero check in ReadExt::skip_bytes,
• at least WriteExt::skip_bytes, optionally the whole WriteExt,
• at least the Encoder impls that require it, optionally all,
• and possibly more, like impl Display for AttestationReport.

default, openssl, and crypto_nossl should then depend on the feature.

Or vice-versa: A feature flag (or even a cfg flag) that disables those parts, to avoid "accidentally" opting in to it by disabling default features.

[DGonzalezVillal]

@cschramm Ok I think this is a solution I can work with. I'll start working on some deliverable for it. Thank you for you patient discussion.

[cschramm]

@DGonzalezVillal: I'm looking forward to the solution. Do you have an update? Can I provide any help?

[DGonzalezVillal]

@cschramm Hello Christopher, I apologize — work on the solution slipped into my backlog for a bit due to other priorities that came up, along with the Thanksgiving holiday. I’m resuming work on it this week, but if you’re able to put something together sooner, I’m happy to review your work instead.