This project started off as a side-project on secure code execution because I wanted to figure out Repl.it and HackerRank worked. I tried experiments with different technologies like Firecracker [1], AWS Lambda [2] and gVisor [3]. They are all great technologies but I ended up with a solution using a combination of VMs and Docker containers to execute user generated code.
[1] https://github.com/firecracker-microvm/firecracker
[2] https://aws.amazon.com/lambda
[3] https://github.com/google/gvisor
In Show HN: CoderTest – TDD/BDD focused programming interviewsgoogle
gvisor
Go2018–2026
google / gvisor
gvisor
Application Kernel for Containers
66Distinct people
82Mentions
1Explicit recommenders
20KGitHub stars
What to know before exploring
What it is
Application Kernel for Containers
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
I recommend reading the GitHub README[1]. > I don't really understand what the benefit is over seccomp-bpf With seccomp-bpf you are filtering what syscalls can be made, but…
antoncohen used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- googleapis/google-cloud-go · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 2:04:58 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year82 dated mentions
Observed mentions: 2018-05-02 10:02:51 UTC to 2026-07-03 07:11:17 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 32 | 6 | 26 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 12 | 0 | 12 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 6 | 0 | 6 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 7 | 1 | 6 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 5 | 0 | 5 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 7 | 1 | 6 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 5 | 0 | 5 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 4 | 0 | 4 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
What is gVisor?
gVisor provides a strong layer of isolation between running applications and
the host operating system. It is an application kernel that implements a
Linux-like interface. Unlike Linux, it is written in a memory-safe
language (Go) and runs in userspace.
gVisor includes an Open Container Initiative (OCI) runtime called runsc
that makes it easy to work with existing container tooling. The runsc runtime
integrates with Docker and Kubernetes, making it simple to run sandboxed
containers.
What isn't gVisor?
gVisor is not a syscall filter (e.g. seccomp-bpf), nor a wrapper over
Linux isolation primitives (e.g. firejail, AppArmor, etc.).
gVisor is also not a VM in the everyday sense of the term (e.g.
VirtualBox, QEMU).
gVisor takes a distinct third approach, providing many security benefits of
VMs while maintaining the lower resource footprint, fast startup, and
flexibility of regular userspace applications.
Why does gVisor exist?
Containers are not a sandbox. While containers have
revolutionized how we develop, package, and deploy applications, using them to
run untrusted or potentially malicious code without additional isolation is not
a good idea. While using a single, shared kernel allows for efficiency and
performance gains, it also means that container escape is possible with a single
vulnerability.
gVisor is an application kernel for containers. It limits the host kernel
surface accessible to the application while still giving the application access
to all the features it expects. Unlike most kernels, gVisor does not assume or
require a fixed set of physical resources; instead, it leverages existing host
kernel functionality and runs as a normal process. In other words, gVisor
implements Linux by way of Linux.
gVisor should not be confused with technologies and tools to harden containers
against external threats, provide additional integrity checks, or limit the
scope of access for a service. One should always be careful about what data is
made available to a container.
Documentation
User documentation and technical architecture, including quick start guides, can
be found at gvisor.dev.
Installing from source
gVisor builds on x86_64 and ARM64. Other architectures may become available in
the future.
For the purposes of these instructions, bazel and other build
dependencies are wrapped in a build container. It is possible to use
bazel directly, or type make help for standard targets.
Requirements
Make sure the following dependencies are installed:
Linux 5.6+
Docker version 17.09.0 or greater
Building
Build a release tarball containing runsc, the containerd-shim-runsc-v1
containerd shim, and a few sidecar binaries that runsc expects to find in a
gvisor-bin/ directory next to itself, then extract it to /usr/local/bin:
make release-tarball DESTINATION=bin/
sudo tar -C /usr/local/bin -xf bin/gvisor.tar.bz2
To build specific libraries or binaries, you can specify the target:
make build TARGETS="//pkg/tcpip:tcpip"
Building directly with Bazel (without Docker)
Using Bazel directly isn't recommended due to the extra overhead, but in order
to get started:
Look at the build dockerfile for the canonical
list of needed dependencies.
Install and use bazelisk. Otherwise, make sure your bazel
version matches the one listed in the .bazelversion file.
After setting up dependencies, using Bazel is similar to the Makefile:
bazel build -c opt //debian:gvisor-release-tar-bz2
Testing
To run standard test suites, you can use:
make unit-tests
make tests
To run specific tests, you can specify the target:
# Makefile
make test TARGETS="//runsc:version_test"
# Bazel
bazel test //runsc:version_test
Mac OS
Some packages support running tests directly on macOS. At the time of this
writing, gVisor requires bazel 8, which you can install via homebrew:
brew install bazel@8
# You can then run the tests, e.g.:
$(brew --prefix bazel@8)/bin/bazel test --macos_sdk_version=$(xcrun --show-sdk-version) -- //tools/nogo/... //tools/check{aligned,const,escape,linkname,locks,unsafe}/...
Using go get
This project uses bazel to build and manage dependencies. A synthetic
go branch is maintained that is compatible with standard go tooling for
convenience. This is useful for external packages and libraries that depend on
gVisor subpackages (e.g. userspace networking via Netstack) to import gVisor Go
code into their Go projects.
Select this branch explicitly with the go branch query. @latest resolves
master, which requires Bazel and is not compatible with standard Go tooling:
go get gvisor.dev/gvisor/pkg/tcpip/transport/tcp@go
NOTE: runsc builds from this branch are not supported. gVisor and
runsc require several binaries (some of which are not even written in Go) in
order to function. The go branch is supported in a best effort capacity, and
direct development on this branch is not supported. Development should occur on
the master branch, which is then reflected into the go branch.
Community & Governance
See GOVERNANCE.md for project governance information.
See ADOPTERS.md for a list of known production users and
adopters.
Join us on the CNCF Slack workspace: use #gvisor
for questions and discussion, and #gvisor-dev for
development and contribution. Before you can join the channels, you must be a
member of the CNCF Slack workspace:
Get an invitation from the self-service page at
slack.cncf.io.
Accept the invitation that you get in your email.
Join the #gvisor and #gvisor-dev
channels.
The gvisor-users mailing list and
gvisor-dev mailing list are also good starting points for
questions and discussion.
Security Policy
See SECURITY.md.
Releases
See Releases.
Contributing
See Contributing.md.
Read the full README on GitHubWhat Hacker News says
12 sourcesHere is an example: https://github.com/google/gvisor - https://github.com/google/gvisor/tree/master/tools/go_generi...
It was useful enough that someone made a standalone package: https://github.com/mmatczuk/go_generics
In Go Creeping InStrengthening the security with virtualization is something that's in the early stage of experimentation and research and will be a long-term project. Over the long term though, the goal is moving away from having the Linux kernel completely other than as the native API / ABI for apps. Projects like https://github.com/google/gvisor are very promising in that regard even if they end up playing no part in how this eventually happens for GrapheneOS. A clearer and much more detailed roadmap will be posted soon. The site is still very newly created and barely has any information about the project.
Essentially, the goal for the project is for it to be an OS compatible with Android apps, using the Android Open Source Project software stack to run them, but the underlying base can become whatever is most suited to the task. For now, the most prac
Read the rest
tical approach is using virtualization to reinforce the app sandbox and user profiles. Eventually, the virtual machines can drop having their own Linux kernels (see gVisor as an example of this). In the very long term, the Linux kernel at the core of the OS could eventually go away too.
I'd recommend checking out the standalone projects like https://github.com/GrapheneOS/hardened_malloc and https://github.com/GrapheneOS/Auditor for an idea of what the project is focused on doing. The hardened_malloc implementation supports other operating systems, as does Auditor, which supports verifying the stock OS on many mobile devices (they need to be added one-by-one to the internal database based on users submitting attestation samples with the app) and CalyxOS in addition to GrapheneOS.
The OS project itself is still in the early stage of reviving it, porting over past work and getting the basics done. It's very focused on the infrastructure and low-level work right now. Working on the higher level features that are more user facing and bundling various apps, etc. is not a priority right now. It doesn't even bundle F-Droid right now, because it's not quite at the point where bundling any third party apps makes sense. It also needs to be determined how to best approach that. A lot of these things will also be done in collaboration with other projects like CalyxOS, with GrapheneOS focusing more on low-level security hardening. CalyxOS is primarily working on areas like the backup service implementation and various other higher-level services, and a lot of this will be used by GrapheneOS too.
The Android Open Source Project is the only viable starting point. I don't know what else you would suggest. It has solid privacy and security as a baseline already, unlike other mobile or desktop Linux-based operating systems. There's also a huge amount of public security research targeting it for both offensive and defensive work. Moving to the desktop Linux stack would drastically set back both privacy and security. It would take a decade of work by dozens of programmers just to catch up, and the goal of the project is advancing the status quo rather than trying to play catch up to it for years. The goal is not creating a new ecosystem for applications and convincing developers to target it, especially if it would be for no particular reason. It needs an existing application ecosystem, so Android app compatibility is of utmost importan
Read the rest
ce.
Having a massive monolithic kernel at the core of the operating system written entirely in a memory unsafe language is obviously a huge problem, and will need to be addressed over the long term. It's an increasingly blatant weakness, and the enormous amount of ongoing work that has gone into userspace doesn't translate well to the kernel. Developing increasingly more sophisticated mitigations helps a bit, but it can't solve the fundamental issues with the choice of language, architecture or development process. Linux ultimately isn't a viable choice for creating a system with decent security. However, Linux compatibility is part of Android compatibility and is essential. That means the Linux kernel either has to be kept around in virtual machines or replaced with a compatibility layer on top of a microkernel. https://github.com/google/gvisor is an existing project which could be ported to arm64, expanded as needed and adjusted to run on top of another kernel but it doesn't need to be the starting point. It's usually a good idea to start from an existing base like this and try to land everything needed upstream though, rather than burning far more resources starting from scratch and losing out on the shared benefits from collaboration with a larger community.
Using virtualization is a nearer term goal, with a compatibility layer as a much longer term aspiration. There's not much written about the roadmap on the linked page, but this stuff is actually mentioned, and I'd recommend checking it out before wrongly assuming that the goal is simply having a hardened fork of AOSP. There has already been substantial work on experimenting with integrating virtualization for app containment, although containing user profiles would be another approach and potentially more useful.
For sure, implementing Linux is no easy task, and there is no magic bullet. For compatibility testing, we have extensive system call unit tests [1] and also run many open source test suites. Language runtime tests (e.g., Python, Go, etc) are particularly useful. We also perform continuous fuzzing with Syzkaller [2].
> how do you implement features that ostensibly require calls to the OS anyways?
gVisor's kernel is a user-space program, so it can and does make system calls to the host OS. Some examples:
* An application blocks trying to read(2) from a pipe. gVisor ultimately implements blocking by waiting on a Go channel. The Go runtime will ultimately implement this with a futex(2) call to the host OS.
* An application reads from a file that is ultimately backed by a file on the host (provided by the Gofer [3]). This will result in a prea
Read the rest
d(2) system call to the host.
The purpose here isn't to avoid the host completely (that's not possible), but to limit exposure to the host. gVisor can implement all the parts of Linux it does on a much smaller subset of host system calls. Anything we don't use is blocked by a second-level seccomp sandbox around the kernel. e.g., the kernel cannot make obscure system calls, or even open files or create sockets on the host (those operations are controlled by an external agent).
[1] https://github.com/google/gvisor/tree/master/test/syscalls/l...
[2] https://github.com/google/syzkaller
[3] https://gvisor.dev/docs/architecture_guide/overview/
(I am co-author of the post)
System calls are important, but only one factor. The linked doc is an attempt to clarify and delineate various costs. There are number of platform options (the platform is what does syscall interception), and I don't believe any of them are 100x so to say "at least" is a bit disingenuous. You may have confused the "runsc-kvm" number with "using a VM". "runsc-kvm" is the system call performance of gVisor using the kvm platform, which is not a full VM [1]. In general the syscall cost in a VM depends entirely on the guest OS, since there is no VMEXIT for this operation.
VMs are a valid choice depending on your workload, and this is providing an additional tool that provides an easy control for containerized infrastructure. You can use what works for you. Native containers certainly work as well, but you'll probab
Read the rest
ly want to consider additional security controls of some form if you're really running untrusted stuff in there.
[1] https://github.com/google/gvisor/tree/master/pkg/sentry/plat...
For anyone who hasn't seen this before. There is a pretty good gVisor Architecture Guide that explains how this works pretty well via a few diagrams [1]. Lots more info on these pages too [2, 3].
> gVisor intercepts application system calls and acts as the guest kernel, without the need for translation through virtualized hardware. gVisor may be thought of as either a merged guest kernel and VMM, or as seccomp on steroids. This architecture allows it to provide a flexible resource footprint (i.e. one based on threads and memory mappings, not fixed guest physical resources) while also lowering the fixed costs of virtualization. However, this comes at the price of reduced application compatibility and higher per-system call overhead.
From what I understand, basically a user-space program that wraps your container and intercepts all system c
Read the rest
alls. You can then allow/deny/re-wire them (based on a config). So, you have pretty much complete control over what your apps can do.
This for me, is sort of the key takeway from the blog post too: "because we use gVisor to increase the security of Google's own internal workloads, it continuously benefits from our expertise and experience running containers at scale in a security-first environment". So, Google's using something like this internally too for their own workloads, which should be a pretty good sign this works in real life.
[1] https://gvisor.dev/docs/architecture_guide/
[2] https://github.com/google/gvisor
[3] https://gvisor.dev/
There's also Google's Gvisor, for also running containers as VMs: https://github.com/google/gvisor
(Handily it works with standard Docker, just put in an extra line in your /etc/docker/daemon.json)
In Nemu – Modern Hypervisor for the Cloud by IntelCloud Run engineer here.
Containers are run in gVisor https://github.com/google/gvisor
as the container sandbox.
In Cloud Run – Newest member of our serverless compute stackI recently had a need for a slack bot that could dynamically select which user to notify each week based on a schedule. /remind would have been perfect for this if it let me do some computation to figure out who to @ in its notification message, so I decided to build that.
The bot currently has 2 slash commands, /sh [`command`] runs the command immediately and returns the output to you, and /notify [@user or #channel] [`command`] [cron expression] will run the command on the cron schedule and notify the user or channel of the output of that command.
At the moment it's running on a single t3.small EC2 instance with a t3.micro RDS database. Cron triggers are stored in the DB, which would allow me to add more worker nodes to distribute the load in future, if there is enough demand.
Each command runs as a non-root user in its own container un
Read the rest
der docker, on top of Google's gVisor kernel (https://github.com/google/gvisor). I've also limited the containers in their resource usage and mounted a read-only root FS (there's also a writeable tmpfs mounted at /data). Each command can run for a maximum of 5 seconds before it is automatically killed.
I'd love to hear your thoughts!
The death of the Docker as a technology is laughable. Every Cloud provider is racing to add container orchestration features and they all use Docker under the hood [1, 2, 3, 4]. Cloud providers are dumping hundreds of millions into this ecosystem through, training, credits, new features, etc. I have not seen anyone step off the gas. They are all seeing massive growth in container adoption. My guess is this is only the start. Go look at any DevOps/SRE job posting and you will see Docker, Containers, Kubernetes. This post is wrong when is comes to the technology going away anytime soon.
Container orchestration is light years better than anything that we were doing on the operations side before. This is why I find it extremely hard to believe we are going back. We would need something much better to jump to and that has not been invented yet
Read the rest
. So, Orchestration/Docker/Containers are here to stay for the foreseeable future.
The rkt image format tried early on to subvert the Docker Image format and was unsuccessful. Today, there is much more depending on the existing image standard. You would totally fragment the existing integrations if you attempted to change. I am not saying that people will not try. But, I just cannot see it happening anytime soon. You have all these Clouds betting on it, you have millions of Dockerfiles out there now, and tons of people trained on it. All these CI/CD platforms supporting it. You would need some massive reason to change. Why would they? You might see people under the hood take the Docker Image and wrap it somehow, like gvisor [5], but they will still likely accept the Docker Image.
Go look at these charts from Datadog about their customers Docker adoption [6]. Every single chart is hockey stick growth. This is a sampling of 10,000 companies running 700 million containers in real-world use. I am just offering a counter to the point that the image format is coming to its death. I do not see that.
Disclosure: Former Docker employee.
[1] https://aws.amazon.com/ecs/
[2] https://aws.amazon.com/eks/
[3] https://cloud.google.com/kubernetes-engine/
[4] https://docs.microsoft.com/en-us/azure/aks/
[5] https://github.com/google/gvisor
[6] https://www.datadoghq.com/docker-adoption/
gVisor is also pretty neat, they say KVM support is experiemental though: https://github.com/google/gvisor
gVisor is used behind Go 1.11 on App Engine so Google must be fairly confident that it's a sufficient security boundary though I'm fairly sure they don't use the public KVM isolation so YMMV.
In CVE-2019-5736: runc container breakout