Put IPCC behind a default-on cargo feature

[plotnick]

sprockets-tls links libipcc unconditionally, so every consumer's binary carries a NEEDED entry for a library that only exists on Oxide sleds. The support shell (sush) client now uses sprockets-tls to secure connections to the switch zone, but it needs to run on non-Oxide machines.

Gate the ipcc module, ResolveSetting::Ipcc, AttestConfig::Ipcc, and the libipcc dependency behind an "ipcc" feature, on by default so existing consumers keep building unchanged.

See also oxidecomputer/sush#31, oxidecomputer/omicron#11034.

🤖 Disclaimer: LLM assistance was used to produce this patch.

[andrewjstone]

@labbott I feel like we discussed this a while back and decided not to do this. I don't remember exactly why. I thought we resolved it another way. Do you remember?

@plotnick We run sprockets on helios machines that aren't sleds all the time. What platforms are you trying to run this on?

[plotnick]

We run sprockets on helios machines that aren't sleds all the time. What platforms are you trying to run this on?

Non-Oxide-sled Helios. The sush client now uses sprockets-tls (in a way that is a conversation for another venue); I built it on Castle, and it failed to run with ld.so.1: sush: fatal: libipcc.so.1: open failed. I was able to get around that by setting LD_LIBRARY_PATH=/usr/platform/oxide/lib/amd64, and could have embedded that path in the binary with linker tricks, but it seemed like kludging around the issue. My thought was that IPCC doesn't even make sense on non-Oxide hardware, so why bother requiring and linking against a library that can't possibly function? Hence this feature-gate.

[labbott]

It's pretty standard to need to specify the path to link with for binaries that need ipcc which is what we do when building sprockets https://github.com/oxidecomputer/sprockets/blob/main/tls/build.rs . Something seems off here that it isn't working with how we're building for sush.

[plotnick]

It's pretty standard to need to specify the path to link with for binaries that need ipcc

The argument here is that the sush client doesn't need (and can't use) ipcc. With this patch, we can compile with sprockets-tls but without ipcc; right now, we would have to link the sush client against libipcc but then never call into it. The context here is that the sush server runs on the rack; the client generally only ever runs on a customer or support person's (non-Oxide-sled) machine. And we want sprockets-tls in the client (as opposed to regular tls) so we can use the ephemeral cert signed by the RoT to secure the transport between client and server.