18 Commits
Author SHA1 Message Date
Zach KoopmansandgVisor bot 230c28bb8d Fix use-after-free in socket pluginStackRW single-block CGO calls
When calling cgo.Read, cgo.Write, and cgo.Sendto with a single-block BlockSeq,
the backing slice address was converted to uintptr via Addr(). Because Go's
garbage collector does not recognize uintptr as a live pointer reference, the
underlying backing array could be collected or reused during the CGO call.
This adds runtime.KeepAlive on the BlockSeq arguments after each single-block
CGO call in ReadToBlocks and WriteFromBlocks.

PiperOrigin-RevId: 968029244
2026-08-20 13:45:38 -07:00
Shayon Mukherjee 5b002692af vfs: skip write tracking for special files on open
Linux skips the mount-level write check when opening a character device, block device, FIFO, or socket, so write-opening /dev/null on a read-only bind mount succeeds.

Mark the remaining FileDescriptions backed by special-file inodes. Also skip overlay copy-up for writable opens of special files; Linux overlayfs applies the same special_file() exception before deciding whether copy-up is required.

Add regression coverage for character devices and FIFOs through read-only bind mounts.
2026-07-28 06:47:46 -04:00
Tan Yifeng e2bd312913 net: Ensure deterministic interface enumeration order
Go map iteration randomness causes network interface enumeration
(getifaddrs, RTM_GETADDR, RTM_GETLINK, /proc/net/*, SIOCGIFCONF)
to return nondeterministic order, breaking applications like
asciidoctor that expect stable ordering across repeated calls.

Since gVisor allocates NIC IDs monotonically (like Linux ifindex),
sorting by NICID is equivalent to registration order. Add
InterfaceIDs() to inet.Stack so all consumer paths iterate in
deterministic ascending-ID order without ad-hoc sorting at each
call site.

Signed-off-by: Tan Yifeng <[email protected]>
2026-04-23 10:16:47 +08:00
gVisor bot 7465eeb020 Merge pull request #12598 from tamird:nogo-more-checks
PiperOrigin-RevId: 873002517
2026-02-20 11:35:37 -08:00
Jamie LiuandgVisor bot d7996a5d9b Remove "AddressSpace activation".
PiperOrigin-RevId: 869302553
2026-02-12 14:55:06 -08:00
Tamir Duberstein 8016912676 Fix S1002 violations and drop suppression 2026-02-10 11:56:11 -08:00
Shailend ChandandgVisor bot 1b8a025e4a Cleanup creds-related funcs and change CapError behavior
- Introduce Credentials.HasRootCapability().
 - Rename Credentials.HasCapability() to Credentials.HasSelfCapability().
 - Rename Task.HasCapability() to Task.HasSelfCapability().
 - Introduce inet.Namespace.HasCapability(ctx).
 - CapError(), invoked by unimplemented syscalls' stubs, now checks
   against the root userns.

All towards making it less easy to evaluate creds relative to self userns
instead of root userns in the future.

PiperOrigin-RevId: 853942212
2026-01-08 17:23:58 -08:00
Shailend ChandandgVisor bot e428bbea51 Fix creds check in linkat(AT_EMPTY_PATH)
linkat(AT_EMPTY_PATH) needs to check for CAP_DAC_READ_SEARCH in the userns in
which the fd was opened, not the userns of the task running linkat().

To get at that userns, vfs.FileDescription now saves a pointer to the creds
at the time of its creation: plumbing these creds in accounts for much of the
diff. This is similar to how `struct file` stores creds in `f_cred` in Linux.

Moreover, since the Linux patch "vfs: relax linkat() AT_EMPTY_PATH..." [1], the
need for this cap is excused if the creds of the calling task are literally
the same as the one stored in the fd.

[1] https://github.com/torvalds/linux/commit/42bd2af5950456d

PiperOrigin-RevId: 853374474
2026-01-07 12:48:17 -08:00
Shailend ChandandgVisor bot 3860ef4de3 socket(): Check for CAP_NET_RAW in the netns-owning userns
And not the userns of the calling Task. Analogous to Linux's
`ns_capable(net->user_ns, CAP_NET_RAW)`.

PiperOrigin-RevId: 843929192
2025-12-12 20:09:51 -08:00
AnilAltinayandgVisor bot be847fb825 Implement SO_PEERCRED socket option for UNIX sockets and its tests.
PiperOrigin-RevId: 828197810
2025-11-04 17:24:56 -08:00
AnilAltinayandgVisor bot 601fd6e05a Automated rollback of changelist 798788535
PiperOrigin-RevId: 803481970
2025-09-05 09:03:06 -07:00
AnilAltinayandgVisor bot eb1c87dc72 Implement SO_PEERCRED socket option for UNIX sockets and its tests.
PiperOrigin-RevId: 798788535
2025-08-24 05:08:00 -07:00
Nayana BidariandgVisor bot f4af3f5378 Do not support netstack s/r for NetworkPlugin mode.
PiperOrigin-RevId: 766311636
2025-06-02 13:12:11 -07:00
Andrei Vagin 67266e9403 Fix a few typos 2025-01-29 21:16:51 -08:00
Jamie LiuandgVisor bot 19f12e64c8 Move //pkg/sentry/kernel/time to //pkg/sentry/ktime.
This avoids needing to rename it everywhere it's imported.

PiperOrigin-RevId: 693930089
2024-11-06 18:13:51 -08:00
Andrei VaginandgVisor bot f7cac3b2b5 tools/bazeldefs: always pass bazel_cgo to go_library
Its value will be known only on the configuration phase,
before that it can be a select directive.

Updates #9266

PiperOrigin-RevId: 678412518
2024-09-24 15:12:58 -07:00
gVisor bot c675420a0f Merge pull request #9551 from amysaq2023:support-external-stack
PiperOrigin-RevId: 677933413
2024-09-23 14:12:32 -07:00
Anqi Shen 3b519026ca Support plugin network stack
This commit supports a third-party network stack as a plugin stack for
gVisor.

The overall plugin package structure is the following:

- pkg/sentry/socket/plugin:
  Interfaces for initializing plugin network stack. It will be used
  in network setting up during sandbox creating.

- pkg/sentry/socket/plugin/stack:
  Glue layer for plugin stack's socket and stack ops with sentry. It
  will also register plugin stack operations if imported.

- pkg/sentry/socket/plugin/cgo:
  Interfaces defined in C for plugin network stack to support.

To build target runsc-plugin-stack, which imports
pkg/sentry/socket/plugin/stack package and enables CGO:

bazel build --config=plugin-tldk runsc:runsc-plugin-stack

(i.e. --config=plugin-tldk indicates that using TLDK as plugin stack)

By using runsc-plugin-stack binary and setting "--network=plugin" in
runtimeArgs, user can use third-party network stack instead of
netstack embedded in gVisor to get better network performance.

Redis benchmark with following setups:
1. KVM platform
2. 4 physical cores for target pod
3. target pod as redis server

Runc:
$redis-benchmark -h [target ip] -n 100000 -t get,set -q
SET: 115207.38 requests per second, p50=0.215 msec
GET: 92336.11 requests per second, p50=0.279 msec

$redis-benchmark -h [target ip] -n 100000 -t get,set -q
SET: 113895.21 requests per second, p50=0.247 msec
GET: 96899.23 requests per second, p50=0.271 msec

$redis-benchmark -h [target ip] -n 100000 -t get,set -q
SET: 126582.27 requests per second, p50=0.199 msec
GET: 95969.28 requests per second, p50=0.271 msec

Runsc with plugin stack:
$redis-benchmark -h [target ip] -n 100000 -t get,set -q
SET: 123915.74 requests per second, p50=0.343 msec
GET: 115473.45 requests per second, p50=0.335 msec

$redis-benchmark -h [target ip] -n 100000 -t get,set -q
SET: 120918.98 requests per second, p50=0.351 msec
GET: 117647.05 requests per second, p50=0.351 msec

$redis-benchmark -h [target ip] -n 100000 -t get,set -q
SET: 119904.08 requests per second, p50=0.367 msec
GET: 112739.57 requests per second, p50=0.375 msec

Runsc with netstack:
$redis-benchmark -h [target ip] -n 100000 -t get,set -q
SET: 59952.04 requests per second, p50=0.759 msec
GET: 61162.08 requests per second, p50=0.631 msec

$redis-benchmark -h [target ip] -n 100000 -t get,set -q
SET: 52219.32 requests per second, p50=0.719 msec
GET: 58719.91 requests per second, p50=0.663 msec

$redis-benchmark -h [target ip] -n 100000 -t get,set -q
SET: 59952.04 requests per second, p50=0.751 msec
GET: 60827.25 requests per second, p50=0.751 msec

Updates https://github.com/google/gvisor/issues/9266

Co-developed-by: Tianyu Zhou <[email protected]>
Signed-off-by: Anqi Shen <[email protected]>
2024-07-12 09:10:13 +00:00