Remove invalid fallback / heuristic logics when determining Attestation Report / TCB Version variants

[hyperfinitism]

The current variant-determination logic in sev contains several fallback behaviors that are either incorrect or no longer justified by current and future hardware. These fallbacks should be removed in favor of explicit errors when the input cannot be interpreted unambiguously.

This issue focuses on sev itself; a related issue will be filed separately for the downstream snpguest.

1. Attestation Report version fallback

Currently, Attestation Report versions other than 2, 3, 4, or 5 are treated as falling back to version 5 (ReportVariant::V5). This is unsafe.

sev/src/firmware/guest/types/snp.rs

Lines 216 to 226 in 6afb12c

	fn decode(reader: &mut impl Read, _: ()) -> Result<Self, std::io::Error> {
	let version: u32 = reader.read_bytes()?;
	Ok(match version {
	0 | 1 => return Err(std::io::ErrorKind::Unsupported.into()),
	2 => Self::V2,
	3 | 4 => Self::V3,
	5 => Self::V5,
	_ => Self::V5,
	})
	}
	}

• The known set of report versions is {2, 3, 4, 5}. (Note: No information about V4 report has been disclosed by AMD...)
• Any version outside this set should be considered invalid or unsupported input.
• Falling back to V5 silently risks mis-parsing an unknown format.

Proposed change

If version is not 2, 3, 4 or 5, return an error instead of falling back to V5.

2. TCB Version / processor model fallback for V2 report

For ReportVariant::V3 or later, the processor model can be determined reliably from CPU_FAM_ID and CPU_MOD_ID, and this approach is already used downstream snpguest. However, for ReportVariant::V2, since V2 reports have neither CPU_FAM_ID nor CPU_MOD_ID, the current code relies on heuristics and fallbacks that are no longer valid.

sev/src/firmware/guest/types/snp.rs

Lines 448 to 467 in 6afb12c

	fn decode(reader: &mut impl Read, _: ()) -> Result<Self, std::io::Error> {
	let mut bytes = vec![0u8; ATT_REP_FW_LEN];
	reader.read_exact(&mut bytes)?;
	let variant = ReportVariant::from_bytes(&bytes[0..4])?;
	let generation = match variant {
	ReportVariant::V2 => {
	if Self::chip_id_is_turin_like(&bytes[CHIP_ID_RANGE])? {
	Generation::Turin
	} else {
	Generation::Genoa
	}
	}
	_ => {
	let family = &bytes[CPUID_FAMILY_ID_BYTES];
	let model = &bytes[CPUID_MODEL_ID_BYTES];
	Generation::identify_cpu(*family, *model)?
	}
	};

Turin heuristic

The code assumes that:

• Turin truncates CPUID to 8 bytes with zero-fill
• If the trailing 54 bytes are zero (so-called "Turin-like"), the CPU is Turin

This assumption is now broken:

• Venice (the successor to Turin) exists
• So "Turin-like" no longer refers to Turin

Genoa fallback

If the CPU is determined to be non–Turin-like, the code falls back to Genoa. This fallback has no clear technical justification and risks misclassifying hardware.

Proposed change

• Remove the Turin-like heuristic for ReportVariant::V2
• (Remove the fallback to Genoa)
• If the processor model cannot be determined unambiguously, return an error

[DGonzalezVillal]

The attestation report fallback issue is being addressed here:
#378

Regarding the TCB version issue, I think there may be a small misunderstanding about how the logic works.

We are not labeling the report as Genoa or Turin when parsing a V2 report.

There are effectively two TCB formats:

Pre-Turin

Turin-forward, which introduced the fmc field and a restructuring of the TCB

Because of this change, it’s necessary to determine whether the CPU is pre-Turin or Turin-forward in order to parse the TCB correctly.

The code does not assume that Turin truncates CPUID to 8 bytes. Turin’s CPUID is 8 bytes, but the total allocated space is 62 bytes, so the remaining bytes are zero-filled in the report.

If the report is determined to be non-Turin, the generation is assigned as Genoa—not because the report is specifically Genoa, but because it represents a pre-Turin generation. Assigning Milan instead would result in the same logic.

At no point is this generation information used for anything other than TCB parsing.

For V2 reports, it’s possible to determine whether the TCB uses the pre-Turin or Turin-forward format by inspecting those bytes. V2 reports do not explicitly include the CPU generation, so this check is how the parser determines the correct TCB layout—no additional information is being added to the report.

The only case where this check would fail is if MaskChipID is present, which causes the chip ID to be all zeros. In that scenario, the check fails outright; it does not fall back to Genoa.

Finally, regarding Venice: it’s unclear whether its chip ID will be short like Turin’s, but this does not affect the logic. Venice will not ship with firmware old enough to produce V2 reports, and the Family and Model fields will always be present.

[hyperfinitism]

As I understand the current code and discussion, the processor model check here is only used to decide which TcbVersion variant should be used when parsing the attestation report, i.e., whether the CPU is pre-Turin or Turin. The value is not otherwise consumed, so even if this heuristic does not exactly match the real processor model, it does not affect correctness. If this understanding is correct, then reusing the Generation enum for this purpose may be semantically misleading, and it might be clearer to introduce a dedicated enum that directly represents the TcbVersion variant instead.

In downstream usage (snpguest), the processor model is also used when fetching the VEK certificate chain, where an exact processor model match is required. Since heuristics are insufficient in this context, similar logic in snpguest should be removed (see virtee/snpguest#149).

[DGonzalezVillal]

That's a good point, I understand how that is confusing. We can create a TCB enum and replace the current Generation logic to make the code clearer.