Boulder without CGO

Background

This isn't planned anytime soon, but something that was on my mind so I thought I'd record some notes.

It would be nice to be able to build Boulder without CGO. That would facilitate easier cross-compilation at least, such as building on arm64 laptops, or deploying binaries from GHA to arm64 cloud instances

I believe the only place we use CGO is for PKCS#11 to talk to the HSM.

Options

P11-kit remoting

We switch to some other standard interface for talking to HSMs. For example, the p11-kit "remoting" protocol for PKCS11 is used in AWS Nitro Enclaves as its interface, and we could use the p11-kit server to wrap our vendor's pkcs11 library. I think there may be other options here too

Subprocess

Use a process-based plugin model to isolate the C_GO code. I think something like Hashicorp's go-plugin could be either used, or serve as a model. Approximately, this means boulder_ca manages a subprocess that handles the CGO parts. All of the configuration for Boulder stays the same, probably just with the addition of a path to the plugin process. go-plugin executes a subprocess and communicates with it over grpc via the subprocess' stdin/stdout, eliminating the need to worry about anything like unix socket paths, permissions, and so on. Or even one-execution-per-signing, but that sounds inefficient.

Sidecar

Pull the core of signing out into a minimal, independent sidecar service. Could be grpc-over-unix socket or similar. It handles all the details of PKCS11 configuration, etc. This does mean we need to be careful about permissions, to ensure only boulder-ca can access the socket. However, this does mean we can do things like run separate containers for the HSM/PKCS11 code, which may be advantageous for other reasons as well.

boulder-ca with CGO

Split all of boulder-ca into its own binary built with CGO, and the rest of boulder can be built without CGO.

Performance

Because we run dedicated, isolated instances for boulder-ca, we have plenty of memory and CPU available, so latency is the only performance concern.

Start by confirming the PKCS#11 HSM integration is the only CGO-dependent path in Boulder. Compare the p11-kit remoting, subprocess plugin, sidecar, and boulder-ca-only options, including cross-compilation and signing latency; the issue does not yet define a selected approach or concrete done criteria.