ae26b2c425
Netstack listen loop can get stuck if cookies are in-use and the app is slow to accept incoming connections. Further we continue to complete handshake for a connection even if the backlog is full. This creates a problem when a lots of connections come in rapidly and we end up with lots of completed connections just hanging around to be delivered. These fixes change netstack behaviour to mirror what linux does as described here in the following article http://veithen.io/2014/01/01/how-tcp-backlog-works-in-linux.html Now when cookies are not in-use Netstack will silently drop the ACK to a SYN-ACK and not complete the handshake if the backlog is full. This will result in the connection staying in a half-complete state. Eventually the sender will retransmit the ACK and if backlog has space we will transition to a connected state and deliver the endpoint. Similarly when cookies are in use we do not try and create an endpoint unless there is space in the accept queue to accept the newly created endpoint. If there is no space then we again silently drop the ACK as we can just recreate it when the ACK is retransmitted by the peer. We also now use the backlog to cap the size of the SYN-RCVD queue for a given endpoint. So at any time there can be N connections in the backlog and N in a SYN-RCVD state if the application is not accepting connections. Any new SYNs will be dropped. This CL also fixes another small bug where we mark a new endpoint which has not completed handshake as connected. We should wait till handshake successfully completes before marking it connected. Updates #236 PiperOrigin-RevId: 250717817 |
||
---|---|---|
.github | ||
g3doc | ||
kokoro | ||
pkg | ||
runsc | ||
test | ||
third_party/gvsync | ||
tools | ||
vdso | ||
.bazelrc | ||
.gitignore | ||
AUTHORS | ||
BUILD | ||
CODE_OF_CONDUCT.md | ||
CONTRIBUTING.md | ||
Dockerfile | ||
LICENSE | ||
Makefile | ||
README.md | ||
WORKSPACE |
README.md
What is gVisor?
gVisor is a user-space kernel, written in Go, that implements a substantial
portion of the Linux system surface. It includes an
Open Container Initiative (OCI) runtime called runsc
that provides an
isolation boundary between the application and the host kernel. The runsc
runtime integrates with Docker and Kubernetes, making it simple to run sandboxed
containers.
Why does gVisor exist?
Containers are not a sandbox. While containers have revolutionized how we develop, package, and deploy applications, running untrusted or potentially malicious code without additional isolation is not a good idea. The efficiency and performance gains from using a single, shared kernel also mean that container escape is possible with a single vulnerability.
gVisor is a user-space 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 user-space 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 currently requires x86_64 Linux to build, though support for other architectures may become available in the future.
Requirements
Make sure the following dependencies are installed:
- Linux 4.14.77+ (older linux)
- git
- Bazel 0.23.0+
- Python
- Docker version 17.09.0 or greater
- Gold linker (e.g.
binutils-gold
package on Ubuntu)
Getting the source
Clone the repository:
git clone https://gvisor.googlesource.com/gvisor gvisor
cd gvisor
Building
Build and install the runsc
binary:
bazel build runsc
sudo cp ./bazel-bin/runsc/linux_amd64_pure_stripped/runsc /usr/local/bin
If you don't want to install bazel on your system, you can build runsc in a Docker container:
make runsc
sudo cp ./bazel-bin/runsc/linux_amd64_pure_stripped/runsc /usr/local/bin
Testing
The test suite can be run with Bazel:
bazel test ...
or in a Docker container:
make unit-tests
make tests
Using remote execution
If you have a Remote Build Execution environment, you can use it to speed up build and test cycles.
You must authenticate with the project first:
gcloud auth application-default login --no-launch-browser
Then invoke bazel with the following flags:
--config=remote
--project_id=$PROJECT
--remote_instance_name=projects/$PROJECT/instances/default_instance
You can also add those flags to your local ~/.bazelrc to avoid needing to specify them each time on the command line.
Community & Governance
The governance model is documented in our community repository.
The gvisor-users mailing list and gvisor-dev mailing list are good starting points for questions and discussion.
Security
Sensitive security-related questions, comments and disclosures can be sent to the gvisor-security mailing list. The full security disclosure policy is defined in the community repository.
Contributing
See Contributing.md.