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
It is an idea of running codespell as part of our presubmit checks.
Before enabling it for new changes, let's fix what it has found.
Signed-off-by: Andrei Vagin <avagin@gmail.com>
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
This replaces the `seccomp.Rule` type with the `seccomp.SyscallRule`
interface, which is an abstraction that defines how to match a syscall's
arguments and RIP.
This has the following benefits:
- The code can verify that rules are self-contained, as the
`SyscallRule.Render` contract specifies that the rule must jump to
either a "matched" or "not matched" label, and may not fall through.
It uses `ProgramBuilder`'s support for asserting unreachability to
enforce this.
- Rules that match everything are more explicit (no more implicit
"no rules means everything matches" behavior, instead you have to
explicitly specify `seccomp.MatchAll{}`).
- "OR" behavior is explicit (a disjunctive rule is marked as `seccomp.Or`
rather than the current implicit meaning of a list of rules).
- Allows the creation of more sophisticated matching rules that don't work
on a per-argument basis. This change does not do any of that yet, it
simply refactors existing rules without changing the way they work.
- Decouples rule-specific rendering code from the larger program generation
code (BST, architecture check, etc.).
Unfortunately there is no easy way to split this change into multiple
sub-changes without introducing additional complexity to support both forms
of expressing rules, so sorry if this is a large change. But note that it
is actually net-negative in line count.
Despite the size of this change, please review it carefully, as this is a
security-sensitive change.
PiperOrigin-RevId: 571459670
This reduces the diff on an upcoming refactor which modifies all seccomp
rules.
`AnyValue` better reflects the fact that the matcher is about matching a
single syscall argument value, as opposed to e.g. a rule that allows a
syscall through regardless of its argument.
PiperOrigin-RevId: 571110444
`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
"procid" implies "process ID", "processor (CPU?) ID", or "`runtime.p.id`". It
is none of these things. Instead, `procid.Current()` returns the caller's host
thread ID; almost every caller relies on this property. Rename the package
accordingly.
Nit: Replace "system thread identifier" with "host thread ID". "System" is
needlessly vague in a setting where many callers will also have an unrelated
application thread ID, and "identifier" is a guess at what is abbreviated by
"thread ID" - but cf. gettid(2), "NAME: gettid - get thread identification".
PiperOrigin-RevId: 507034135
The syscall package has been deprecated in favor of golang.org/x/sys.
Note that syscall is still used in the following places:
- pkg/sentry/socket/hostinet/stack.go: some netlink related functionalities
are not yet available in golang.org/x/sys.
- syscall.Stat_t is still used in some places because os.FileInfo.Sys() still
returns it and not unix.Stat_t.
Updates #214
PiperOrigin-RevId: 360701387
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
The support of PTRACE_SYSEMU on arm64 was added in the 5.3 kernel,
so we can be sure that the current version is higher that 5.3.
And this change moves vsyscall seccomp rules to the arch specific file,
because vsyscall isn't supported on arm64.
PiperOrigin-RevId: 298696493
Linux PTRACE_SYSEMU support on arm64 was merged to mainline from
V5.3, and the corresponding support in go also enabled recently.
Since the "syscall" package is locked down from go 1.4, so the ptrace
PTRACE_SYSEMU definition can't be added to package "syscall" on arm64.
According to the golang community, updates required by new systems or
versions should use the corresponding package in the golang.org/x/sys
repository instead(https://golang.org/pkg/syscall/).
Signed-off-by: Haibo Xu <haibo.xu@arm.com>
Change-Id: I2f917bb2be62f990c3e158e2bb99e094ea03f751
Before https://golang.org/cl/173160 syscall.RawSyscall would zero out
the last three register arguments to the system call. That no longer happens.
For system calls that take more than three arguments, use RawSyscall6 to
ensure that we pass zero, not random data, for the additional arguments.
PiperOrigin-RevId: 271062527
Right now, if we can't create a stub process, we will see this error:
panic: unable to activate mm: resource temporarily unavailable
It would be better to know the root cause of this "resource temporarily
unavailable".
PiperOrigin-RevId: 255656831
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
Etienne PerotandgVisor bot
Andrei Vagin
Jamie LiuandgVisor bot
Ayush RanjanandgVisor bot
Andrei VaginandgVisor bot
Ian LewisandgVisor bot
Haibo Xu
Adin ScannellandShentubot
Michael PrattandShentubot