From e5f2478bee8dcc2e4b6f215592acf07c083725b7 Mon Sep 17 00:00:00 2001 From: Etienne Perot Date: Tue, 13 Jun 2023 15:06:40 -0700 Subject: [PATCH] `runsc`: Make Systrap the default platform. As per announced on gvisor-users: https://groups.google.com/g/gvisor-users/c/OhGupJ5bTuo PiperOrigin-RevId: 540085417 --- g3doc/architecture_guide/performance.md | 16 +++++++++------- g3doc/user_guide/production.md | 4 ++-- runsc/config/flags.go | 2 +- test/README.md | 2 +- test/benchmarks/README.md | 4 ++-- test/syscalls/README.md | 18 ++++++++++++------ 6 files changed, 27 insertions(+), 19 deletions(-) diff --git a/g3doc/architecture_guide/performance.md b/g3doc/architecture_guide/performance.md index b89facfd3..3e4e149f3 100644 --- a/g3doc/architecture_guide/performance.md +++ b/g3doc/architecture_guide/performance.md @@ -36,7 +36,7 @@ improvements are possible and not possible. While we include a variety of workloads here, it’s worth emphasizing that gVisor may not be an appropriate solution for every workload, for reasons other than performance. For example, a sandbox may provide minimal benefit for a trusted -database, since _user data would already be inside the sandbox_ and there is no +database, since *user data would already be inside the sandbox* and there is no need for an attacker to break out in the first place. ## Methodology @@ -45,9 +45,11 @@ All data below was generated using the [benchmark tools][benchmark-tools] repository, and the machines under test are uniform [Google Compute Engine][gce] Virtual Machines (VMs) with the following specifications: - Machine type: n1-standard-4 (broadwell) - Image: Debian GNU/Linux 9 (stretch) 4.19.0-0 - BootDisk: 2048GB SSD persistent disk +``` +Machine type: n1-standard-4 (broadwell) +Image: Debian GNU/Linux 9 (stretch) 4.19.0-0 +BootDisk: 2048GB SSD persistent disk +``` Through this document, `runsc` is used to indicate the runtime provided by gVisor. When relevant, we use the name `runsc-platform` to describe a specific @@ -57,9 +59,9 @@ gVisor. When relevant, we use the name `runsc-platform` to describe a specific platform. The `ptrace` platform works everywhere and does not require hardware virtualization or kernel modifications but suffers from the highest structural costs by far. This platform is used to provide a clear understanding of the -performance model, but in no way represents an ideal scenario. In the future, -this guide will be extended to bare metal environments and include additional -platforms.** +performance model, but in no way represents an ideal scenario; users should use +Systrap for best performance in most cases. In the future, this guide will be +extended to bare metal environments and include additional platforms.** ## Memory access diff --git a/g3doc/user_guide/production.md b/g3doc/user_guide/production.md index 179f12353..8468ad696 100644 --- a/g3doc/user_guide/production.md +++ b/g3doc/user_guide/production.md @@ -112,8 +112,8 @@ bare-metal machines** (not VMs). In such a setup, use the KVM platform for best performance. If you absolutely must run gVisor in a virtual machine, we recommend using the -`ptrace` platform. This platform has the most flexibility, but its performance -will lag behind that of KVM and the GKE Sandbox platform. +`systrap` platform. This platform has the most flexibility, but its performance +will lag behind that of KVM. Configure Platform » diff --git a/runsc/config/flags.go b/runsc/config/flags.go index 085e91e40..2b37dd591 100644 --- a/runsc/config/flags.go +++ b/runsc/config/flags.go @@ -69,7 +69,7 @@ func RegisterFlags(flagSet *flag.FlagSet) { flagSet.Bool("strace-event", false, "send strace to event.") // Flags that control sandbox runtime behavior. - flagSet.String("platform", "ptrace", "specifies which platform to use: ptrace (default), kvm.") + flagSet.String("platform", "systrap", "specifies which platform to use: systrap (default), ptrace, kvm.") flagSet.String("platform_device_path", "", "path to a platform-specific device file (e.g. /dev/kvm for KVM platform). If unset, will use a sane platform-specific default.") flagSet.Var(watchdogActionPtr(watchdog.LogWarning), "watchdog-action", "sets what action the watchdog takes when triggered: log (default), panic.") flagSet.Int("panic-signal", -1, "register signal handling that panics. Usually set to SIGUSR2(12) to troubleshoot hangs. -1 disables it.") diff --git a/test/README.md b/test/README.md index cda307d03..a192e41dc 100644 --- a/test/README.md +++ b/test/README.md @@ -34,7 +34,7 @@ There are a few other interesting variations for image and integration tests: * overlay: sets writable overlay inside the sentry * hostnet: configures host network pass-thru, instead of netstack -* kvm: runsc the test using the KVM platform, instead of ptrace +* kvm: runsc the test using the KVM platform, instead of systrap The test will build runsc, configure it with your local docker, restart `dockerd`, and run tests. The location for runsc logs is printed to the output. diff --git a/test/benchmarks/README.md b/test/benchmarks/README.md index 7f8391ffe..27fa53d34 100644 --- a/test/benchmarks/README.md +++ b/test/benchmarks/README.md @@ -28,8 +28,8 @@ To run, use the Makefile: make benchmark-platforms BENCHMARKS_TARGET=path/to/target ``` -The above command will install runtimes/run benchmarks on ptrace and kvm as well -as run the benchmark on native runc. +The above command will install runtimes/run benchmarks on systrap and kvm as +well as run the benchmark on native runc. Benchmarks are run with root as some benchmarks require root privileges to do things like drop caches. diff --git a/test/syscalls/README.md b/test/syscalls/README.md index 9e0991940..057872d86 100644 --- a/test/syscalls/README.md +++ b/test/syscalls/README.md @@ -16,20 +16,23 @@ must be followed for new tests. Each test file generates three different test targets that run in different environments: -* a `native` target that runs directly on the host machine, -* a `runsc_ptrace` target that runs inside runsc using the ptrace platform, and -* a `runsc_kvm` target that runs inside runsc using the KVM platform. +* a `native` target that runs directly on the host machine +* a `runsc_systrap` target that runs inside runsc using the systrap platform +* a `runsc_ptrace` target that runs inside runsc using the ptrace platform +* a `runsc_kvm` target that runs inside runsc using the KVM platform. For example, the test in `access_test.cc` generates the following targets: -* `//test/syscalls:access_test_native` -* `//test/syscalls:access_test_runsc_ptrace` -* `//test/syscalls:access_test_runsc_kvm` +* `//test/syscalls:access_test_native` +* `//test/syscalls:access_test_runsc_systrap` +* `//test/syscalls:access_test_runsc_ptrace` +* `//test/syscalls:access_test_runsc_kvm` Any of these targets can be run directly via `bazel test`. ```bash $ bazel test //test/syscalls:access_test_native +$ bazel test //test/syscalls:access_test_runsc_systrap $ bazel test //test/syscalls:access_test_runsc_ptrace $ bazel test //test/syscalls:access_test_runsc_kvm ``` @@ -41,6 +44,9 @@ tag: # Run all tests in native environment: $ bazel test --test_tag_filters=native //test/syscalls/... +# Run all tests in runsc with systrap: +$ bazel test --test_tag_filters=runsc_systrap //test/syscalls/... + # Run all tests in runsc with ptrace: $ bazel test --test_tag_filters=runsc_ptrace //test/syscalls/...