default feature "sev" prohibits compilation on non x86_84 targets

[mkulke]

Is this intentional? in trustee there are some target archs (aarch64, s390) that would be able to verify SNP evidence, but you cannot currently build the "sev" feature on those platforms, because "arch::_cpuid" is used, which is x86 specific. This means a consumer has to disable default-features for this crate. However, if a transitive dependency on the sev crate is introduced and that one doesn't disable default-features, the sum of all features will be enabled, and compilation will fail. E.g.

trustee.deps:
- sev v=7, default-features=false,features=["serde"]
- some-crate v=1

some-crate.deps:
- sev v=7, default-features=true,

=> trustee.deps.sev.features = [default.., serde]

if it's unintentional, maybe a ci job w/ default features on an arm runner could help?

[cclaudio]

Some time ago @fitzthum pushed the #329 to fix a cpuid call. It looks like that the rdrand dependency also should to be behind a x86_64 arch flag and fallback to openssl when in non-x86 arch.

With that, trustee would be able to run the SNP verifier in a non-x86 platform and use the sev crate to verify the SNP attestation report.

[mythi]

It looks like that the rdrand dependency also should to be behind a x86_64 arch flag and fallback to openssl when in non-x86 arch.

That was covered by #340. AFAUI the remaining question is if sev default feature is intentional or not (this issue).

[BbolroC]

It looks like that the rdrand dependency also should to be behind a x86_64 arch flag and fallback to openssl when in non-x86 arch.

@cclaudio sorry, I misunderstood your point (I removed the old comment). Yes, you are right. And falling back to openssl is great because of FIPS certification. Thanks!

[mkulke]

That was covered by #340. AFAUI the remaining question is if sev default feature is intentional or not (this issue).

exactly. do we want this work on non-x86_64 systems...

cargo init
cargo add sev
cargo build

or are the consumers of the crate required to find a permutation of features that will work on their target?

If we want the former, this could be ensured by putting those 3 lines in a workflow w/ runs-on: ubuntu-24.04-arm

[hyperfinitism]

I think this issue ultimately comes from a deeper architectural mismatch in the current sev crate design.

At the moment, the crate bundles together:

• guest-only functionality (e.g. SEV guest device access, CPUID-based switching, RDRAND usage),
• host-only functionality (ASP / firmware interaction),
• non-arch functionality (e.g. attestation report structures).

As a result, even consumers that only need non-arch data definitions (for example, a remote verifier implementation) end up pulling in x86_64-specific code and dependencies. This makes it difficult to use the crate in non-x86 environments or in contexts where guest/host functionality is fundamentally irrelevant.

The current feature-based workarounds (such as falling back to OpenSSL to avoid certain arch-specific dependencies) do not reflect the actual semantic boundaries but just to suppress undesirable dependencies.

From a design perspective, it seems the root issue is that architectural boundaries (guest vs host vs others, arch-dependent vs arch-independent) are not aligned with crate or feature boundaries.

A more principled solution would likely involve either:

• introducing explicit, role-based features (e.g. guest, host), or
• splitting the crate into multiple crates (for example, a purely non-arch core crate for data structures and verification, plus arch-specific guest/host crates).

I understand that this would be a breaking change and not something to do lightly, but it seems difficult to fully resolve the problem without addressing this structural separation.