The OCI spec has entrypoint as the first argument in specs.Process.Args.
During testing, we observed inconsistencies in entrypoint resolution: it
was resolved during checkpoint but not during restore (or vice versa),
leading to spec validation failures. This CL corrects this by comparing the
absolute paths of entrypoints in spec validation.
PiperOrigin-RevId: 733200146
Replaces the flag "unsafe-skip-restore-spec-validation" with
"restore-spec-validation" which allows the user to set the level of restore
spec validation such as ignore, warning or enforce. This allows user to skip
validation if required. By default, the flag will be set to "enforce" which
will perform spec validation.
This is a breaking change for users who have enabled
--unsafe-skip-restore-spec-validation flag. We advise these users to use the
new flag introduced in this change: --restore-spec-validation and set it to
"warning" or "ignore". This setting (--restore-spec-validation=warning) gives
the same behavior as when the old flag was enabled.
PiperOrigin-RevId: 719045616
This wraps `nvproxy`'s `ioctl` handlers with wrappers that are
driver-capability-aware, and initially populates the ABI tree
with all functions marked as being available for capabilities
`compute` and `utility`.
It is not yet possible for the user to specify which capability
they want to enable. This should not cause a regression for users
because the hardcoded effective capability set is the one that is
currently specified for all current handlers.
Updates #9452.
Updates #10856.
PiperOrigin-RevId: 697824737
As part of sandbox startup, `runsc` needs to set up a chroot environment
with a minimal working `procfs` filesystem mounted within. However, doing
so from within a container (as applications like Dangerzone do) may fail,
because in the container runtime's default configuration, some paths of the
procfs filesystem visible from within the container may be obstructed. This
prevents mounting new unobstructed instances of `procfs`.
This change detects this case and falls back to the previous behavior of
using a recursive bind-mount of `/proc` in such a case. The obstructed
subdirectories of procfs are preserved in this case, which is fine because
we only need a very minimal subset of `procfs` to actually work.
Additionally, `runsc` actually only needs a few kernel parameter files
and `/proc/self` in order to work. So this change sets up a `tmpfs` mount
that contains just those files, with the kernel parameter files being
plainly copied and `/proc/self` being a symlink to the one present in the
mounted view of `procfs` (regardless of which mounting method was used).
The `runtime_in_docker` test will continuously verify that this fallback
mechanism works to avoid similar breakage in the future.
Credits to @avagin for figuring out this solution.
Fixes#10944.
PiperOrigin-RevId: 692310347
runsc attempts to emulate nvidia-container-runtime-hook. But it was always
passing "--compute --utility" as driver capability flags to
`nvidia-container-cli configure` command.
Fix runsc to emulate nvidia-container-runtime-hook correctly by parsing
NVIDIA_DRIVER_CAPABILITIES and converting that comma-separated list to flags.
This is in preparation for adding support for non-compute GPU workloads in
nvproxy :)
Updates #9452
Updates #10856
PiperOrigin-RevId: 678064565
It has not been the real cause of recent failures.
If it turns out to result in new bug reports that do end up being caused by
`max_user_namespaces` being too low, then IMO the proper fix would be to add
a check for this at `runsc` startup time instead of here at process fork/exec
time.
Updates #5964
PiperOrigin-RevId: 659712753
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
We have a few gVisor-specific mount options that can be set "externally" (see
pkg/fsimpl/gofer.SupportedMountOptions). Before this change, the meaning of
"externally" was that it could be set by runsc by appending the option to
spec.Mount.Options. This change expands the meaning of "externally" to the user
defined OCI spec.
It does so by making specutils.validateMountOption() allow "unknown" options.
(By unknown here I mean options not present in optionsMap and propOptionsMap.)
This only impacts gofer mounts. There are 2 places in which the mount options
are consumed, both of which don't break due to bogus options:
1. Some of the mount options are used to create the host bind mount in gofer's
mount namespace. See runsc/cmd/gofer.go:setupMounts(); it only extracts
options present in optionsMap and propOptionsMap. It will disregard any
other user-defined options.
2. The mount options are passed to the fsimpl/gofer sentry-internal mount. See
runsc/boot/vfs.go:getMountNameAndOptions(). It consumes what it understands
and ignores the rest (logging a warning that it is doing so).
Fixes#10316
PiperOrigin-RevId: 628341966
This flag is no longer needed when using nvproxy with Docker or legacy mode of
nvidia-container-runtime. In both these cases, runsc will detect the presence
of the nvidia-container-runtime-hook and perform necessary emulation.
For backward compatibility, this flag still has the effect of injecting the
nvidia-container-runtime-hook into container prestart hooks.
PiperOrigin-RevId: 608875827
We still bind mount /sys/devices/pci0000:00/<pci_address>/accel/accel# files
into the sandbox process in read-only mode for all TPU devices on host.
PiperOrigin-RevId: 582021030
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
Tested on a T4 GPU with driver version 525.60.13:
```
$ docker run --runtime=runsc --gpus=all --rm -it nvcr.io/nvidia/k8s/cuda-sample:vectoradd-cuda11.7.1-ubi8
[Vector addition of 50000 elements]
Copy input data from the host memory to the CUDA device
CUDA kernel launch with 196 blocks of 256 threads
Copy output data from the CUDA device to the host memory
Test PASSED
Done
```
Also tested this on GKE with the same vectoradd workload. Checked that the
device gofer connection is actually being closed when the container is deleted.
Something to note is that the gofer logs for the GPU-container sometimes end
abruptly (the "All lisafs servers exited." line does not print). This is
because runsc/container/container.go:stop() SIGKILLs the gofer before it can
cleanup naturally. The device gofer connection is only closed at the end of
Loader.destroySubcontainer(), which gives little time before the gofer is
SIGKILL-ed.
PiperOrigin-RevId: 581365665
Nayana BidariandgVisor bot
Stepan Koltsov
Andrei Vagin
Etienne PerotandgVisor bot
Jonathon Belotti
Koichi Shiraishi
Ayush RanjanandgVisor bot
Lucas ManningandgVisor bot
Fabricio VoznikaandgVisor bot
dongjinlong
Jing ChenandgVisor bot
Zach KoopmansandgVisor bot