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
There is a race in the test where the goroutine running Container.executeSync()
calls WaitPID() => IsSandboxRunning() which accesses Container.Sandbox.
This can race with the defer Container.Destroy which sets Sandbox = nil.
This race was introduced in 0968254ce7 ("Speed up container_test") which got
rid of the read on channel `ch`.
Fix the race by exec-ing asynchronously. This maintains the old behavior of not
checking if the exit status of sleep.
Fixes 0968254ce7 ("Speed up container_test")
PiperOrigin-RevId: 736572600
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
Exec'd processes cannot be stitched back to the original caller
and are killed after restore. So ignore failures
to restore host FDs (generally stdio) that belong
to them.
Fixes#11439
PiperOrigin-RevId: 732972054
- 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
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
Before this change, the gofer filestore FDs were opened in the host's mount
namespace. This prevented containerd from unmounting a subcontainer's rootfs
in case (due to a ref leak or bug) the container's rootfs was not destroyed in
gVisor's VFS layer. In such a scenario, the sentry would leak the rootfs
filestore FD and containerd's umount attempts will fail with EBUSY.
This change ensures that all gofer filestores are created in the gofer's mount
namespace, so any unmount attempt from the host mount namespace is not blocked.
This change makes the following 2 logical changes:
1. It introduces a new gofer process synchronization flag --sync-chroot-fd. The
gofer waits on this FD and then proceeds to set up container filesystem and
pivot_root(2) + chroot(2) the gofer mount namespace. This is useful if an
external process wants to take action in gofer's mount namespace while
having access to the host filesystem. As a result, the existing
--sync-nvproxy-fd became redundant because it has the same use case. IOW,
it was just renamed to "sync-chroot-fd" and its meaning became broader.
2. Container.createGoferFilestores() earlier was doing two things: creating
gofer mount configs and creating all filestores. But the intent of this
change is to only create filestore FDs after gofer starts in gofer mountns.
However, the gofer mount configs are needed before that. So this function
was split into Container.initGoferConfs().
We open FDs from the gofer mount namespace using a neat trick suggested by
Andrei, we prefix the absolute paths with /proc/<gofer-pid>/root. See
proc_pid_root(5) for more details about this.
There are no other intended changes in behavior.
Fixes#9834
Suggested-by: Andrei Vagin <avagin@google.com>
PiperOrigin-RevId: 706880500
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
The gofer process can encounter permission issues accessing volumes when custom
user/group mappings are defined within its user namespace. To address this, the
gofer now attempts to open volumes from the initial userns as a fallback
mechanism.
Fixes#11040
PiperOrigin-RevId: 694341928
Nayana BidariandgVisor bot
Ayush RanjanandgVisor bot
Fabricio VoznikaandgVisor bot
Stepan Koltsov
Andrei Vagin
Etienne PerotandgVisor bot
Jonathon Belotti
Jing Chen
Koichi Shiraishi
Nicolas LacasseandgVisor bot