By default in runsc, we have both IPv4 and IPv6 addresses enabled on all the
interfaces. However, in runc this is based on the sysctl
net.ipv6.conf.all.disable_ipv6. This CL will make runsc behave similar to runc.
- If net.ipv6.conf.all.disable_ipv6 is > 0, then only IPv4 addresses will be
enabled on the interfaces including loopback when network mode is "sandbox".
PiperOrigin-RevId: 737656607
- SandboxCheckpointedMetric and SandboxRestoredMetric are added for sandbox
metadata metric which indicate whether sandbox is checkpointed or restored.
- NumCheckpointedSandboxesMetric and NumRestoredSandboxesMetric are added at
the process level which will get the count of number of sandboxes being
checkpointed and restored.
PiperOrigin-RevId: 726797010
This adds a `hostsettings` package which can be used to check and
optionally automatically adjust host kernel settings.
This currently covers six kernel settings:
- `/proc/sys/kernel/yama/ptrace_scope`: must set to 0 or 1 when using
`ptrace`.
- `/proc/sys/user/max_user_namespaces`: must be >= 2, but also
suggest increasing it further if low.
- `/proc/sys/kernel/unprivileged_userns_clone`: Must be enabled in
rootless mode.
- `/proc/sys/kernel/unprivileged_userns_apparmor_policy`: Same.
- `/proc/sys/vm/max_map_count`: suggest increasing max host VMAs.
- `/sys/kernel/mm/transparent_hugepage/shmem_enabled`: suggest turning
on transparent hugepages.
This is flag-gated; by default `runsc` only checks that these settings
are optimal, but only warns if they are not optimal (unless marked as
mandatory). Other flag settings can be used to either bypass this process
entirely (to avoid the small startup overhead this adds), or to make it
auto-adjust any suboptiomal kernel settings, either on a best-effort or
mandatory basis.
Updates issue #5964
Updates issue #9006
PiperOrigin-RevId: 683375555
When a pages file is provided to `runsc restore`, reads from that file are
asynchronous (via statefile.AsyncReader) in order to maximize throughput.
However, all such reads must complete before Kernel.LoadFrom() returns, so
applications cannot execute before MemoryFile loading is complete. The main
objective of this CL is to allow reads to continue after Kernel.LoadFrom()
returns, allowing applications to execute while MemoryFile loading is still in
progress. This behavior is user-visible: it affects whether deleting the pages
file frees disk space immediately on POSIX filesystems, may affect whether
deletion is possible on non-POSIX filesystems, and prevents unmounting
regardless. Thus it is flag-guarded as `runsc restore --background`.
MemoryFile ranges that have yet to be loaded, but that are being waited-for by
applications, should be prioritized over ranges for which no application is
waiting. This requires that application requests for data (calls to
MemoryFile.(memmap.File).DataFD/MapInternal()) are able to determine which
ranges have not yet been loaded, request reads for such ranges with elevated
priority, and wait for only those reads to be completed; none of these are
supported by the existing statefile.AsyncReader.
Thus:
- Add //pkg/sentry/pgalloc/aio, which provides an async I/O API that is
designed to be easily implementable using a goroutine pool, Linux native AIO,
or io_uring, though only includes a goroutine pool implementation. (io_uring
is widely disabled due to security vulnerabilities. In my testing, Linux
native AIO is slower than the goroutine pool, but this may change with lower
GOMAXPROCS which needs further testing.)
- Move I/O scheduling into pgalloc: introduce an async page loader goroutine
that is started by MemoryFile.LoadFrom() when async page loading is requested
(implicitly, via the existence of a pages file), which is responsible for
driving submission of read requests and handling their completions.
PiperOrigin-RevId: 679321884
Recently printf.Analyzer has become stricter
(https://github.com/golang/go/issues/60529)
which led to new findings.
gvisor nogo tests run this analyzer and fail if it produces findings.
PiperOrigin-RevId: 671657227
The sandbox process was executed in the current pid namespace if a target
platform used ptrace. It was the workaround for the kernel issue that was
fixed by 8fb335e07837 ("kernel/exit.c: release ptraced tasks before
zap_pid_ns_processes"). This fix was back-ported to stable branches.
PiperOrigin-RevId: 668121544
The rootDir path can change if the runsc caller is invoking runsc from a
different mount namespace (for example from within a privileged container).
Sandbox.sandboxConnect() tries to use this path to connect to the sandbox.
PiperOrigin-RevId: 661340742
After 19249c0724f2 ("net: make net.core.{r,w}mem_{default,max} namespaced")
/proc/sys/net/core/rmem_default is present in non-initial netns as well.
/proc/sys/net/core/dev_weight has existed from the beginning of Linux git repo
in 1da177e4c3f4 ("Linux-2.6.12-rc2"). So it should be safe to use this file.
Demo:
```
$ sudo ip netns add foo
$ sudo ip netns exec foo stat /proc/sys/net/core/dev_weight
stat: cannot statx '/proc/sys/net/core/dev_weight': No such file or directory
$ sudo ip netns delete foo
```
Fixes#10704
PiperOrigin-RevId: 658087447
This command waits for (n-1)th checkpoint to complete successfully. Then waits
for the next checkpoint attempt (which would increment checkpoint count to n)
and returns its status.
If sandbox checkpoint count has already reached n, it returns immediately.
PiperOrigin-RevId: 651884599
Prior to this change, the log files each have their own timestamp computed
independently. For example, this means that the coverage log file, the panic
log file, the debug log file, the first Gofer's log file, and the profile
files for the same Sentry may all have different timestamps in their
filenames. Now they are the same.
This change introduces a central `runsc/starttime` package for which the sole
purpose is to hold the start time of the `runsc` process, for easy plumbing
in all places that need it.
PiperOrigin-RevId: 646667986
Nayana BidariandgVisor bot
Ayush RanjanandgVisor bot
Andrei Vagin
Fabricio VoznikaandgVisor bot
Etienne PerotandgVisor bot
Kevin KrakauerandgVisor bot
Jamie LiuandgVisor bot
Anqi Shen