While precompilation is pretty fast, its presence in the build graph
removes concurrency from the `runsc` build process. This is because the
precompilation generation binary is dependency-heavy (e.g. it needs all
platform implementations), yet must be built before the `//runsc/boot/filter`
package is built, thus slowing down the `runsc` build process.
This change creates a low-dependency "stubbed" version of this generation
binary when running in `fastbuild` mode. The generated code in this mode
contains no precompiled seccomp programs; they are instead all built from
scratch on container startup. This trades off build speed vs container
startup speed.
PiperOrigin-RevId: 586520033
Prior to this change, the Sentry seccomp filters use the program's PID
as filter to the `tgkill(2)` system call. However, some platforms expand
this filter to allow any PID, which the optimizer detects and optimizes
the initial filter away. So the PID ends up being treated as an unused
variable. This change addresses this by detecting this situation and
allowing unused variables in optimized bytecode, so long as they do show
up in non-optimized bytecode.
Also add some small helper functions for using 64-bit variables.
PiperOrigin-RevId: 583222206
This adds a `precompiledseccomp` library which provides tooling to compile
`seccomp-bpf` programs and generate Go source code that contains the
resulting bytecode embedded into it. In turn, this bytecode can be used in
Go libraries.
This avoids spending time compiling and optimizing `seccomp-bpf` programs
at runsc container creation time.
This library also contains support for "variables", which are `uint32`s whose
values are part of the seccomp filters but only known at runtime. To support
this, the program is compiled twice with placeholder values for these
variables, and we verify that the offsets at which these values show up in the
bytecode is consistent across these two compilation attempts.
PiperOrigin-RevId: 583117683
Etienne PerotandgVisor bot
Jing ChenandgVisor bot