build: make runc binary 7.6% smaller

[xnox]

In general runc does not do any cryptography or TLS networking.

go-systemd module has optional support for TLS. It is compiled by default, and pulls in all of crypto/tls stack into the binary. Despite being unused, it is not optimised out, as there is no sophisticated LTO-like functionality in go toolchain.

By removing this single file from the vendored modules, runc binary size is 7.6% smaller (both stripped and unstripped).

This also has a nice compliance side effect - the only other cryptography modules pulled in are crypto/rand and crypto/sha1 neither of which are used to protect information at rest or in-transit, meaning the same build of runc can be used in FIPS and non-FIPS contexts, as not using any cryptography make the binary out of scope for FIPS cryptographic module compliance.

If this is of interest, will also proposed to go-systemd project to add a build tag, to allow building go-systemd without tls-listeners.

[cyphar]

Fwiw, I would prefer a build tag...

[xnox]

Fwiw, I would prefer a build tag...

Ack! Let me try to submit a build tag upstream.

[kolyshkin]

Perhaps we can just copy the activation.Files code to runc?

[kolyshkin]

Perhaps we can just copy the activation.Files code to runc?

Something like this: https://github.com/opencontainers/runc/pull/5057

[akhilerm]

This also has a nice compliance side effect - the only other cryptography modules pulled in are crypto/rand and crypto/sha1 neither of which are used to protect information at rest or in-transit, meaning the same build of runc can be used in FIPS and non-FIPS contexts, as not using any cryptography make the binary out of scope for FIPS cryptographic module compliance.

sha1 is not allowed in the go fips 140-only mode. It will cause a panic at runtime. So I dont think unless crypto/sha1 usage is also removed, the runc binary will not be completely out of scope for FIPS compliance.

[cyphar]

But yeah, I think #5057 is an even better solution than a build tag.

[xnox]

This also has a nice compliance side effect - the only other cryptography modules pulled in are crypto/rand and crypto/sha1 neither of which are used to protect information at rest or in-transit, meaning the same build of runc can be used in FIPS and non-FIPS contexts, as not using any cryptography make the binary out of scope for FIPS cryptographic module compliance.

sha1 is not allowed in the go fips 140-only mode. It will cause a panic at runtime. So I dont think unless crypto/sha1 usage is also removed, the runc binary will not be completely out of scope for FIPS compliance.

Correct, however the approach taken by golang toolchain doesn't match what I.G.2.4.A allows. The point is that one doesn't need to build runc using FIPS mode toolchain at all.

Also sha1 could be replaced with sha1cd.

[kolyshkin]

Also sha1 could be replaced with sha1cd.

Could you elaborate? runc does not use crypto/sha1 directly; I found two uses in the vendored libraries, those are:

• in cilium/ebpf (the only user is (asm.Instructions).Tag method which afaics we don't use);
• in godbus/dbus (the only user is _windows.go file so it is not included during compile time).