This page is served by a pod running under the gVisor runtime
(runtimeClassName: gvisor) on an F5 Distributed Cloud Customer Edge,
reached through a CE-advertised load balancer.
uname -a inside this container:Linux gvisor-echo-6c4b54f4d8-pp6jc 4.19.0-gvisor #1 SMP Sun Jan 10 15:06:54 PST 2016 x86_64 GNU/LinuxThe CE host actually runs Linux 5.14 (RHEL 9). This container sees 4.19.0-gvisor - a different kernel, because gVisor gave it one of its own.
A normal container (runc) shares the host Linux kernel directly.
Run uname -r in a runc container on this same CE and you would see the
host 5.14 kernel - the app is one kernel CVE or container escape away from the host.
Under gVisor the container gets its own kernel, implemented in userspace - the gVisor Sentry. Every system call this app makes is intercepted and re-interpreted by the Sentry; the host kernel is never directly exposed. A kernel exploit, a fork bomb, a namespace escape - it stays inside the sandbox. That is the point of gVisor: a real isolation boundary for untrusted workloads, such as AI agents running generated code.
/proc/version:Linux version 4.19.0-gvisor #1 SMP Sun Jan 10 15:06:54 PST 2016
/proc/sentry-meminfo:
present - a proc entry that exists only inside a gVisor Sentry.
/proc/cpuinfo model name: unknown - gVisor
synthesizes CPU info; the real host CPU model is not passed through.The gVisor Sentry boots a kernel in userspace. Its dmesg is unmistakable:
[ 0.000000] Starting gVisor... [ 0.386030] Politicking the oom killer... [ 0.493801] Searching for socket adapter... [ 0.506404] Adversarially training Redcode AI... [ 0.794459] Recruiting cron-ies... [ 1.257314] Checking naughty and nice process list... [ 1.578987] Waiting for children... [ 1.635189] Verifying that no non-zero bytes made their way into /dev/zero... [ 1.646236] Daemonizing children... [ 1.910864] Creating cloned children... [ 2.305204] Creating process schedule... [ 2.568321] Ready!
busybox httpd in a gVisor sandbox - F5 ADSP edge AI gateway PoC.