This is meant to make #12557 possible to implement, i.e.
making it possible for the seccomp configuration to specify actions
other than deny/allow in the main `runsc` configuration. This change
doesn't do that but it adds the structures to make that possible.
PiperOrigin-RevId: 868246148
This adds a `HottestSyscalls` function to the `Platform` interface, as the
platform determines which syscalls are most often called by the Sentry.
This is used by the Sentry seccomp filter code to build the final list of
hot syscalls.
PiperOrigin-RevId: 582833363
This does an optimization pass over `RuleSet`s prior to rendering anything,
rather than optimizing at the last minute for each syscall.
PiperOrigin-RevId: 581671748
This is just a refactoring, but the intention of this `struct` is to add
other useful options for the program build, such as the list of expected
"hottest" syscalls by frequency.
The interface is a bit awkward, because of the need for two entry points
(one which didn't have any way to set the default actions), and because the
zero value of `linux.BPFAction` is a valid (and common) "default action":
killing the program (`linux.SECCOMP_RET_KILL_THREAD`).
We also can't use `*linux.BPFAction`, as `linux.SECCOMP_RET_*` are constants.
So the struct fields use functions that "resolve" to an action.
This reads fairly well in the call sites (`DefaultAction: Return(action)`),
at the cost of slightly convoluted logic in `seccomp.go`.
PiperOrigin-RevId: 581477348
This creates a duplicate BPF interpreter which keeps track of the
instructions and input bytes it accesses.
Having such a mode is useful for the following reasons:
- For seccomp-bpf programs that the Sentry enforces from the sandboxed
application, this allows it to check whether the program is
deterministic based solely on the syscall number. For such syscalls,
we can cache the result of executing the program, and never run the
interpreter during syscall execution. (This optimization is not yet
implemented, but this change enables it to be.)
- For verification of correctness, coverage-based fuzzing is necessary.
I plan to implement a fuzz-based test which verifies that the
optimized and unoptimized versions of the same seccomp-bpf programs
have the same behavior, and ensuring that the corpus achieves full
coverage is necessary to ensure a good degree of correctness.
However, this mode is slower than it needs to when evaluating the
program in an application syscall (which is a very hot path), so this
has to live in a separate (sadly duplicated) function. The tests are
expanded to verify the for instrumented output, but also verify that
the "fast" version (aka the previous implementation) behaves the exact
same way, so this prevents the risk that code from one will drift away
behavior-wise.
To illustrate how much slower (not to mention it does allocations):
```
│ with_binary_order_removed │
│ sec/op │
Interpreter 14.26n ± 0%
InstrumentedInterpreter 98.37n ± 3%
```
PiperOrigin-RevId: 576562506
This removes the interface indirection from BPF evaluation, which is
a very hot path (runs for every application syscall for seccomp'd containers)
and simplifies the code in general.
```
│ initial │ hey_look_no_interfaces │
│ sec/op │ sec/op vs base │
Interpreter 26.31n ± 0% 21.12n ± 0% -19.73% (p=0.000 n=21+20)
```
PiperOrigin-RevId: 576375947
This wraps the `map[uintptry]SyscallRule` into an unexported field of a struct
so that it cannot be accessed directly.
This is helpful for the `runsc` and `fsgofer` seccomp filters which are quite
complex and built across multiple files and multiple functions, where it is
not always clear which order they are executed in. By forcing mutations to be
more explicit about their intent (especially "merge with this new rule" vs
"override what happens for this syscall with this new rule"), we can crash if
that intent isn't what's actually happening.
PiperOrigin-RevId: 572361619
`bpf.Instruction` is the same type as `linux.BPFInstruction`, except that it
uses the BPF instruction-to-string decoder to give a nice human-readable
stringification.
PiperOrigin-RevId: 570499020
The first step to optimizing something is to measure it.
This creates a `secbench` library which can benchmark the time it takes to
run an application "Profile", which is a weighted-random set of syscall
sequences, under a given `seccomp-bpf` filter.
The `secbench` library runs two subprocesses which run the same set of system
calls using this application profile. One of the subprocesses runs with the
seccomp-bpf filter, and the other one runs without it. The library computes
the difference, and reports this duration as the time it takes to run the
seccomp-bpf filter for that system call. It also reports the overall time it
takes to run the weighted-random set of system calls, useful as a general
measure of the overhead that the application will see.
PiperOrigin-RevId: 567704927
