Build output depends on environment

[frankdavid]

We use the SEV crate in our project that must be built reproducibly and we verify that each of our crate dependencies is reproducible as well.

The SEV crate's build.rs depends on whether /dev/sev or /dev/sev-guest is available. This causes the build to have a different output based on the machine where the build takes place. It'd be nice if there was a way (e.g. with a feature flag) to compile the crate such that the output does not depend on the build environment.

[DGonzalezVillal]

Hey @frankdavid,

The difference between /dev/sev and /dev/sev-guest depends on whether the OS is running on physical hardware or in a virtualized environment. So the build output isn't really tied to the machine itself, but rather to the environment it's running in. This distinction is important because the hardware interfaces available differ depending on whether you're on a host or a guest. For example, attestation reports can't be requested from a guest.

That said, I believe no features are gated based on whether you're building for host or guest — only certain tests are conditionally compiled based on that distinction to avoid running host tests in a guest and vice-versa. We could certainly force a manual compilation flag if needed, but I wanted to share this context in case it helps clarify your issue.

If you're running SEV tests, it's best to test guest-specific functionality inside a guest, and host-specific functionality on a host.

[tylerfanelli]

Hey @frankdavid,

The difference between /dev/sev and /dev/sev-guest depends on whether the OS is running on physical hardware or in a virtualized environment. So the build output isn't really tied to the machine itself, but rather to the environment it's running in. This distinction is important because the hardware interfaces available differ depending on whether you're on a host or a guest. For example, attestation reports can't be requested from a guest.

But I believe @frankdavid's point is about reproducibility of builds to verify that the build that eventually runs on the SEV host/guest can be verified, no matter where it is built.

@frankdavid Is this what causes the build output to be different? And by "different output" what specifically do you mean? A measurement of some sort?

[nmattia]

hi! chiming in because I'm the one pestering @frankdavid about reproducibility.

@frankdavid's point is about reproducibility of builds to verify that the build that eventually runs on the SEV host/guest can be verified, no matter where it is built.

Indeed!

We try to ensure our builds are reproducible for several reasons. First for security and transparency, so that downstream users can verify the artifacts we publish. Then for build efficiency — we use the bazel build system (though this applies to other build systems like Nix, buck, etc) and ensuring the build artifacts are reproducible means pre-built cache artifacts can be distributed to build machines (regardless of the machines the artifacts were built on). Finally we perform pretty aggressive (per-object) reproducibility checks to ensure no flakiness sneaks in, which might in time lead to the source not being buildable (due to dependency upgrades, external sources having disappeared, etc).

@frankdavid Is this what causes the build output to be different? And by "different output" what specifically do you mean? A measurement of some sort?

Yes, most likely!

We could certainly force a manual compilation flag if needed, but I wanted to share this context in case it helps clarify your issue.

Would it be possible to have a manual flag/feature/environment variable drive the build, and (if not present) default to the current heuristics?

Happy to give more context if necessary!

[tylerfanelli]

I honestly wouldn't mind removing those checks from the build.rs in general. It really was an oversight to tie the build environment to anything about the machine it would run on. The two should not be dependent. It's entirely unreasonable to expect that this library will always be built on SEV capable machines.

@DGonzalezVillal do you agree?

[DGonzalezVillal]

I'm not against this. I agree that build environment being dependent on the machine is being built on was a weird design choice. I'm open to a PR to move away from this. I personally don't have the bandwidth to implement it right now although.