I've been conducting a series of application security reviews for a multi-tenant data processing platform where agents execute potentially untrusted user-supplied code. Our initial isolation layer was gVisor, chosen for its lower overhead compared to full microVMs. A recurring challenge has been constraining the fork bomb scenario—while gVisor provides kernel isolation, a malicious or buggy agent process can still spawn a debilitating number of subprocesses within the sandbox, consuming allocated resources and causing denial-of-service within its own container.

My objective is to enforce a strict limit on the number of concurrent processes or threads a single agent (or its entire pod) can create from within the gVisor sandbox. The standard Linux `pids` cgroup controller is, of course, operational at the container runtime (Docker, containerd) level, but I am specifically interested in controls that are enforced by the gVisor sandbox kernel itself, providing a second, in-depth layer of limitation that is agnostic to the outer runtime configuration.

From my analysis of the gVisor source and documentation, I see several potential avenues, but the exact mechanism and its security guarantees are unclear:

* **gVisor's own cgroup support:** The sentry can be configured to run inside a cgroup hierarchy. Does applying a `pids.max` limit at the level where the `runsc` sandbox process itself runs propagate correctly and restrict the total number of processes *inside* the sandbox? Or does the sandbox process count as a single process from the host perspective, rendering this ineffective for intra-sandbox limits?
* **`runsc` configuration flags:** The `--cpu-num` and `--mem` flags limit overall resources, but I have not found a direct `--max-procs` or similar. Is process limitation purely a function of the memory limit?
* **ptrace vs. KVM platform:** Would the choice of platform affect the efficacy of any host-level cgroup constraints? I suspect the KVM platform, with its more discrete kernel, might interact with host cgroups differently than the ptrace platform.
* **In-sandbox kernel parameters:** Is it possible (or advisable) to manipulate the sandboxed kernel's `kernel.pid_max` or `kernel.threads-max` via a `runsc boot` configuration file? For example:
```json
{
"sysctl": {
"kernel.pid_max": "512",
"kernel.threads-max": "1024"
}
}
```
Does gVisor respect these limits within its virtualized kernel, and would this provide the intended intra-sandbox constraint?

The ideal solution would be a configuration that ensures that even if the outer `pids` cgroup limit is circumvented or misconfigured, the sandbox itself imposes a hard ceiling. I am seeking a methodical, defense-in-depth approach. Has anyone implemented or tested such a configuration in a production or testing environment? Concrete `runsc` command-line examples or boot configuration snippets would be immensely valuable for my analysis.

-- nina