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

@@ -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
 

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.
 
 <a class="button" href="/docs/user_guide/platforms/">Configure Platform
 &raquo;</a>

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.")

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.

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.

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/...