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.

[labbott]

This feels a little strange because we've typically only done Local <-> Local or IPCC <-> IPCC for connections and this introduces Local <-> IPCC. Is the Local configuration sufficient for representing what sush needs or do we need a 3rd category of connection category to better represent this case?

[plotnick]

Is the Local configuration sufficient for representing what sush needs or do we need a 3rd category of connection category to better represent this case?

I can't answer that from the design POV of this library, as I am very new to it. I can say that I agree this is a new use case, and came out of discussions with Claude on how to secure the sush client ↔️ switch zone proxy connection. This is covered briefly in a new Transport Security section of RFD 620 (which we can augment or revise as needed, of couse), but is also listed as an open question as to whether it's kosher, because it could be considered a violation of the one-key-one-use principle (or not, depending on how you look at it). But it is fully implemented and working right now, and I have no other plausible ideas for how to secure that link, so if we decide that this isn't right or ok for some reason, I'd definitely appreciate suggestions on alternatives.

Also more than happy to chat live if that's helpful, arrange a meeting, etc. I had been resigned for some months to living with self-signed certs for the proxy, but the actual implementation of that on the client side (TOFU, address collisions, cert warnings on every sled reboot) was looking absolutely horrible, and not at all confidence inspiring for the user. I think this solution is simple, elegant, and secure, but am always open to feedback.

The current implementation is spread across three pieces, which may (or may not) provide more context and/or reassurance:

• the sush client
• the switch-zone proxy
• the draft Omicron integration, #11034

[labbott]

https://github.com/oxidecomputer/omicron/pull/11034/changes#diff-4ea3359eebee6d6a38e5fbb713210813c0838f8c62a7e6de76f8ee23856fff02R61-R64 this part answers my question . I have a light preference for adding another resolve type to be more explicit but maybe @andrewjstone can tell me if I'm being too pedantic and this is actually fine (and I actually think it's very cool that this works!)