This records the precise behavior of "return" instructions in the fragment,
rather than simply recording whether there was a "return" instruction at
all. In turn, this allows a caller to verify which return value is returned.
This is useful in an upcoming change to the BST struct, where the fragment
being recorded now has the potential to return (not just jump), and so it
becomes useful to check that the return values it can return are those we
expect.
PiperOrigin-RevId: 581422796
This is useful for value matching rules which look for the value of the `A`
register. If they do not modify this value, then we do not need to reload it
between sequential matchers over the same data.
PiperOrigin-RevId: 577266390
This adds a new `Record` function to `bpf.ProgramBuilder`, which returns a
function to stop recording that returns the "fragment" of the program made
of the instructions that were added between the time `Record` was called and
the time the stop function was called.
This fragment can in turn be interrogated for which `Outcomes` may happen
from executing it: returning a value, jumping to a label, jumping away from
the fragment, falling through.
This is useful while building complex BPF programs with nested rules. By
recording instructions added by a possibly-nested set of rules (the final
outcome of which is to jump to a known set of labels), we can now actually
verify the assertion that the instructions that were added indeed end up
jumping to one of the expected labels, and nothing else.
This is useful not just for safety but also optimization purposes. In an
upcoming refactor to argument matching code, I plan to add a "value matcher"
interface that renders rules that verify the value of the `A` register. Some
matchers may need to modify the `A` register in order to work, but others
don't. By checking whether the set of instructions modifies `A` or not, the
higher-level code can determine whether or not it needs to add code to reload
the value of the `A` register or not before moving on to the next matcher.
PiperOrigin-RevId: 571087694
`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
OCI configuration includes support for specifying seccomp filters. In runc,
these filter configurations are converted into seccomp BPF programs and loaded
into the kernel via libseccomp. runsc needs to be a static binary so, for
runsc, we cannot rely on a C library and need to implement the functionality
in Go.
The generator added here implements basic support for taking OCI seccomp
configuration and converting it into a seccomp BPF program with the same
behavior as a program generated by libseccomp.
- New conditional operations were added to pkg/seccomp to support operations
available in OCI.
- AllowAny and AllowValue were renamed to MatchAny and EqualTo to better reflect
that syscalls matching the conditionals result in the provided action not
simply SCMP_RET_ALLOW.
- BuildProgram in pkg/seccomp no longer panics if provided an empty list of
rules. It now builds a program with the architecture sanity check only.
- ProgramBuilder now allows adding labels that are unused. However, backwards
jumps are still not permitted.
Fixes#510
PiperOrigin-RevId: 331938697
Based on the guidelines at
https://opensource.google.com/docs/releasing/authors/.
1. $ rg -l "Google LLC" | xargs sed -i 's/Google LLC.*/The gVisor Authors./'
2. Manual fixup of "Google Inc" references.
3. Add AUTHORS file. Authors may request to be added to this file.
4. Point netstack AUTHORS to gVisor AUTHORS. Drop CONTRIBUTORS.
Fixes#209
PiperOrigin-RevId: 245823212
Change-Id: I64530b24ad021a7d683137459cafc510f5ee1de9
Jing Chen
Etienne Perot
Ian Lewis
Adin Scannell
Michael Pratt
Ian Gudger
Googler