feat(fetch): add fetch crl subcommand

[hyperfinitism]

This PR introduces a new subcommand:

snpguest fetch crl

The command fetches Certificate Revocation Lists (CRLs) directly from the AMD Key Distribution Service (KDS). With this change, snpguest can now retrieve all attestation collateral (AMD CA certs, VEKs, and CRLs).

Usage

# Fetch CRL of the user-provided processor model
snpguest fetch crl $ENCODING $CERTS_DIR $PROCESSOR_MODEL --endorser $ENDORSER

# Fetch CRL of the processor-model written in the attestation report
snpguest fetch crl $ENCODING $CERTS_DIR --report $ATT_REPORT_PATH --endorser $ENDORSER

See the updated README.md for more details.

Test Environment

• VM: Google Cloud N2D n2d-highmem-4
• Processor: AMD EPYC 7B13 (Milan)
• OS image: ubuntu-accelerator-2404-amd64-with-nvidia-570-v20250819
• Kernel: 6.14.0-1016-gcp

Test code

mkdir workspace
cd workspace

snpguest fetch crl der . milan -e vcek # => crl.der
sleep 10 # avoid rate-limits
snpguest fetch crl pem . milan -e vcek # => crl.pem
sleep 10
openssl crl -inform der -in crl.der # stdout is identical to crl.pem

sudo snpguest report report.bin report-data.bin -r -v 0 # => report.bin
snpguest fetch crl der . -r report.bin -e vcek # => crl.der
sleep 10
snpguest fetch crl pem . -r report.bin -e vcek # => crl.pem
sleep 10
openssl crl -inform der -in crl.der # stdout is identical to crl.pem

[hyperfinitism]

Thank you for reviewing. I have addressed all of the requested changes:

• replaced pem-rfc7468 with openssl::x509::X509Crl
• updated README.md to state that the crl subcommand has the same command line arguments as ca
• lowercased all error messages in the crl module
• removed the unnecessary else block when opening a file

[DGonzalezVillal]

Code looks good to me, I just want to know why there are changes in the lock file.

[DGonzalezVillal]

Why are there changes to the lock file?

[hyperfinitism]

The changes in the lock file came from an earlier commit when pem-rfc7468 was used. I have cleaned this up and removed those changes.

[DGonzalezVillal]

Thank you!

[tylerfanelli]

LGTM, one comment.

[tylerfanelli]

This will only work correctly on Turin+ correct? The attestation report in the previous architectures do not contain the processor model.

[hyperfinitism]

It should work on pre-Turin CPUs as well. For report versions < 3, the logic is Turin-only as you said, but for report versions ≥ 3 the CPU family ID is used to determine the processor model.

snpguest/src/fetch.rs

Lines 114 to 152 in ce3c022

	pub fn get_processor_model(att_report: AttestationReport) -> Result<ProcType> {
	if att_report.version < 3 {
	if [0u8; 64] == *att_report.chip_id {
	return Err(anyhow::anyhow!(
	"Attestation report version is lower than 3 and Chip ID is all 0s. Make sure MASK_CHIP_ID is set to 0 or update firmware."
	));
	} else {
	let chip_id = *att_report.chip_id;
	if chip_id[8..64] == [0; 56] {
	return Ok(ProcType::Turin);
	} else {
	return Err(anyhow::anyhow!(
	"Attestation report could be either Milan or Genoa. Update firmware to get a new version of the report."
	));
	}
	}
	}
	let cpu_fam = att_report
	.cpuid_fam_id
	.ok_or_else(|| anyhow::anyhow!("Attestation report version 3+ is missing CPU family ID"))?;
	let cpu_mod = att_report
	.cpuid_mod_id
	.ok_or_else(|| anyhow::anyhow!("Attestation report version 3+ is missing CPU model ID"))?;
	match cpu_fam {
	0x19 => match cpu_mod {
	0x0..=0xF => Ok(ProcType::Milan),
	0x10..=0x1F | 0xA0..0xAF => Ok(ProcType::Genoa),
	_ => Err(anyhow::anyhow!("Processor model not supported")),
	},
	0x1A => match cpu_mod {
	0x0..=0x11 => Ok(ProcType::Turin),
	_ => Err(anyhow::anyhow!("Processor model not supported")),
	},
	_ => Err(anyhow::anyhow!("Processor family not supported")),
	}
	}

I have verified that it works correctly on a Milan CPU with report version 5. Since the report version is determined by the SEV firmware, upgrading the firmware raises the report version and enables the --report argument to work correctly. This is the same logic already used in the existing fetch ca and fetch vcek subcommands.

[tylerfanelli]

So, we basically mandate that one must update their firmware to use this command properly, correct?

[hyperfinitism]

Yes, that is correct when using the --report flag to identify the processor model (rather than specifying the processor model explicitly). The same applies to the snpguest fetch ca command.