hanzoai/visor
2
0
Fork 0
mirror of https://github.com/hanzoai/visor.git synced 2026-09-24 17:04:14 +00:00
Code Issues Packages Projects Releases Wiki Activity
11,937 Commits 1 Branch 280 Tags
master
Commit Graph
3 Commits
Author SHA1 Message Date
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 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
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