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. |
Could you elaborate? runc does not use crypto/sha1 directly; I found two uses in the vendored libraries, those are:
|
In our fork we patched the vendored code to use sha1cd, to prevent crypto subsystem import (and hence exploding the size of the binary due to FIPS being pulled in)
Will check if it is imported, because if it is, it will be compiled in and linked. It looked essential, but if that too can simply be nuked that would be even better.
Yes, with up to date dbus with my changes to live sha1 out that's true. A while back, sha1 there was pulled in for all OS. |
|
yeah other things still pull in crypto/ and we will work on upstreaming patches to those things in the various dependencies. If there is interested in making runc crypto-free by monkey-patching dependencies, we can propose these here too. For us, it unlocks using runc universally in commercial and FIPS environments without needing to recompile the binary. (cc @markusboehme) |
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.