build: make runc binary 7.6% smaller #5056
Conversation
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. Signed-off-by: Dimitri John Ledkov <[email protected]>
xnox
force-pushed
the
smaller-runc-binary
branch
from
103cd3c to
1305765
Compare
|
Fwiw, I would prefer a build tag... |
Ack! Let me try to submit a build tag upstream. |
When listeners.go APIs are not used by a given application, golang doesn't automatically optimize them out. Add an opt-out build tag to activation/listeners.go, such that one can build an application that uses activation files without the listeners APIs. For applications that do not already include any "crypto/tls" this can be highly beneficial, for example runc can reduce it's total binary size by 7.6%. runc project already uses go mod vendor, and can just delete the listeners.go file: - opencontainers/runc#5056 But it would be preffered if this opt-out build-tag was available here upstream for people to use in general.
|
Perhaps we can just copy the |
Something like this: #5057 |
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. |
|
But yeah, I think #5057 is an even better solution than a build tag. |
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. |
4 participants
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.