| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Speeds up the socket stress tests by a couple orders of magnitude.
PiperOrigin-RevId: 361721050
|
|
PiperOrigin-RevId: 361196154
|
|
|
|
|
|
This validates that struct fields if annotated with "// checklocks:mu" where
"mu" is a mutex field in the same struct then access to the field is only
done with "mu" locked.
All types that are guarded by a mutex must be annotated with
// +checklocks:<mutex field name>
For more details please refer to README.md.
PiperOrigin-RevId: 360729328
|
|
While I'm here, simplify the comments and unify naming of certain stats
across protocols.
PiperOrigin-RevId: 360728849
|
|
|
|
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
|
|
|
|
PiperOrigin-RevId: 359591577
|
|
|
|
One precondition of VFS.PrepareRenameAt is that the `from` and `to` dentries
are not the same. Kernfs was not checking this, which could lead to a deadlock.
PiperOrigin-RevId: 359385974
|
|
|
|
Before this CL, VFS2's overlayfs uses a single private device number and an
autoincrementing generated inode number for directories; this is consistent
with Linux's overlayfs in the non-samefs non-xino case. However, this breaks
some applications more consistently than on Linux due to more aggressive
caching of Linux overlayfs dentries.
Switch from using mapped device numbers + the topmost layer's inode number for
just non-copied-up non-directory files, to doing so for all files. This still
allows directory dev/ino numbers to change across copy-up, but otherwise keeps
them consistent.
Fixes #5545:
```
$ docker run --runtime=runsc-vfs2-overlay --rm ubuntu:focal bash -c "mkdir -p 1/2/3/4/5/6/7/8 && rm -rf 1 && echo done"
done
```
PiperOrigin-RevId: 359350716
|
|
|
|
PiperOrigin-RevId: 359334029
|
|
`runsc ps` currently return pid for a task's immediate pid namespace,
which is confusing when there're multiple pid namespaces. We should
return only pids in the root namespace.
Before:
```
1000 1 0 0 ? 02:24 250ms chrome
1000 1 0 0 ? 02:24 40ms dumb-init
1000 1 0 0 ? 02:24 240ms chrome
1000 2 1 0 ? 02:24 2.78s node
```
After:
```
UID PID PPID C TTY STIME TIME CMD
1000 1 0 0 ? 12:35 0s dumb-init
1000 2 1 7 ? 12:35 240ms node
1000 13 2 21 ? 12:35 2.33s chrome
1000 27 13 3 ? 12:35 260ms chrome
```
Signed-off-by: Daniel Dao <dqminh@cloudflare.com>
|
|
|
|
Restrict ptrace(2) according to the default configurations of the YAMA security
module (mode 1), which is a common default among various Linux distributions.
The new access checks only permit the tracer to proceed if one of the following
conditions is met:
a) The tracer is already attached to the tracee.
b) The target is a descendant of the tracer.
c) The target has explicitly given permission to the tracer through the
PR_SET_PTRACER prctl.
d) The tracer has CAP_SYS_PTRACE.
See security/yama/yama_lsm.c for more details.
Note that these checks are added to CanTrace, which is checked for
PTRACE_ATTACH as well as some other operations, e.g., checking a process'
memory layout through /proc/[pid]/mem.
Since this patch adds restrictions to ptrace, it may break compatibility for
applications run by non-root users that, for instance, rely on being able to
trace processes that are not descended from the tracer (e.g., `gdb -p`). YAMA
restrictions can be turned off by setting /proc/sys/kernel/yama/ptrace_scope
to 0, or exceptions can be made on a per-process basis with the PR_SET_PTRACER
prctl.
Reported-by: syzbot+622822d8bca08c99e8c8@syzkaller.appspotmail.com
PiperOrigin-RevId: 359237723
|
|
|
|
PiperOrigin-RevId: 359235699
|
|
|
|
Reported-by: syzbot+f2489ba0b999a45d1ad1@syzkaller.appspotmail.com
PiperOrigin-RevId: 358866218
|
|
|
|
This removes a three-lock deadlock between fdnotifier.notifier.mu,
epoll.EventPoll.listsMu, and baseEndpoint.mu.
A lock order comment was added to epoll/epoll.go.
Also fix unsafe access of baseEndpoint.connected/receiver.
PiperOrigin-RevId: 358515191
|
|
|
|
PiperOrigin-RevId: 358445320
|
|
|
|
Also skips a test if the setsockopt to increase send buffer did not result in an
increase. This is possible when the underlying socket is a host backed unix
domain socket as in such cases gVisor does not permit increasing SO_SNDBUF.
PiperOrigin-RevId: 358285158
|
|
|
|
These are bumped to allow early testing of Go 1.17. Use will be audited closer
to the 1.17 release.
PiperOrigin-RevId: 358278615
|
|
|
|
This change also adds support for Router Alert option processing on
incoming packets, a new stat for Router Alert option, and exports
all the IP-option related stats.
Fixes #5491
PiperOrigin-RevId: 358238123
|
|
|
|
PiperOrigin-RevId: 358078157
|
|
|
|
See https://github.com/golang/go/issues/19367 for rationale. Note that the
upstream decision arrived at in that thread, while useful for some of our use
cases, doesn't account for all of our SliceHeader use cases (we often use
SliceHeader to extract pointers from slices in a way that avoids bounds
checking and/or handles nil slices correctly) and also doesn't exist yet.
PiperOrigin-RevId: 358071574
|
|
|
|
Note that this CL reorders overlayEntry.copyMu before overlayEntry.dirCacheMu
in the overlayFileOperations.IterateDir() => readdirEntries() path - but this
lock ordering is already required by overlayRemove/Bind() =>
overlayEntry.markDirectoryDirty(), so this actually just fixes an
inconsistency.
PiperOrigin-RevId: 358047121
|
|
|
|
This change implements TLP details enumerated in
https://tools.ietf.org/html/draft-ietf-tcpm-rack-08#section-7.5.3
Fixes #5085
PiperOrigin-RevId: 357125037
|
|
|
|
PiperOrigin-RevId: 357106080
|
|
|
|
PiperOrigin-RevId: 357090170
|
|
|
|
PiperOrigin-RevId: 357031904
|
|
|
|
PiperOrigin-RevId: 357015186
|
