mirror of
https://github.com/netbirdio/gvisor.git
synced 2026-05-22 17:12:49 -07:00
Merge pull request #10936 from EtiennePerot:blog-improvements
PiperOrigin-RevId: 677218401
This commit is contained in:
@@ -15,6 +15,8 @@ plugins:
|
||||
- jekyll-sitemap
|
||||
site_url: https://gvisor.dev
|
||||
feed:
|
||||
title: "gVisor blog"
|
||||
url: https://gvisor.dev
|
||||
path: blog/index.xml
|
||||
svg:
|
||||
optimize: true
|
||||
|
||||
@@ -16,6 +16,8 @@ and _platform portability_ (run gVisor wherever Linux OCI containers run).
|
||||
Delivering on each of these goals requires careful security considerations and a
|
||||
robust design.
|
||||
|
||||
<!--/excerpt-->
|
||||
|
||||
## What does "sandbox" mean?
|
||||
|
||||
gVisor allows the execution of untrusted containers, preventing them from
|
||||
|
||||
@@ -8,6 +8,8 @@ networking architecture of gVisor, and the tradeoffs involved. In particular, we
|
||||
will cover how these principles culminated in two networking modes, how they
|
||||
work, and the properties of each.
|
||||
|
||||
<!--/excerpt-->
|
||||
|
||||
## gVisor's security architecture in the context of networking
|
||||
|
||||
Linux networking is complicated. The TCP protocol is over 40 years old, and has
|
||||
|
||||
@@ -13,6 +13,8 @@ gVisor's security. While gVisor is not immune to vulnerabilities,
|
||||
[we take several steps](https://gvisor.dev/security/) to minimize the impact and
|
||||
remediate if a vulnerability is found.
|
||||
|
||||
<!--/excerpt-->
|
||||
|
||||
## Escaping the Container
|
||||
|
||||
First, let’s describe how the discovered vulnerability works. There are numerous
|
||||
|
||||
@@ -6,6 +6,8 @@ requires expensive bare-metal machines or cloud instances to run safely with
|
||||
good performance, increasing cost and complexity for Cloud users. gVisor,
|
||||
however, takes a more flexible approach.
|
||||
|
||||
<!--/excerpt-->
|
||||
|
||||
**NOTE 2024-05**: This post describes the ptrace and KVM platforms, which were
|
||||
the only two gVisor platforms at the time it was written. The
|
||||
[Systrap platform](/blog/2023/04/28/systrap-release/) was added since and
|
||||
|
||||
@@ -4,6 +4,8 @@ gVisor has implemented the [RACK](https://datatracker.ietf.org/doc/html/rfc8985)
|
||||
(Recent ACKnowledgement) TCP loss-detection algorithm in our network stack,
|
||||
which improves throughput in the presence of packet loss and reordering.
|
||||
|
||||
<!--/excerpt-->
|
||||
|
||||
TCP is a connection-oriented protocol that detects and recovers from loss by
|
||||
retransmitting packets. [RACK](https://datatracker.ietf.org/doc/html/rfc8985) is
|
||||
one of the recent loss-detection methods implemented in Linux and BSD, which
|
||||
|
||||
@@ -10,6 +10,8 @@ many measures. As a container runtime, gVisor provides container-native security
|
||||
without sacrificing resource efficiency. Therefore, it has been on our radar
|
||||
since it was released.
|
||||
|
||||
<!--/excerpt-->
|
||||
|
||||
However, there have been performance concerns raised by members of
|
||||
[academia](https://www.usenix.org/system/files/hotcloud19-paper-young.pdf) and
|
||||
[industry](https://news.ycombinator.com/item?id=19924036). Users of gVisor tend
|
||||
|
||||
@@ -9,6 +9,8 @@ provides the ability for an external process to observe application behavior and
|
||||
detect threats at runtime. Using this mechanism, gVisor users can watch actions
|
||||
performed by the container and generate alerts when something unexpected occurs.
|
||||
|
||||
<!--/excerpt-->
|
||||
|
||||
A monitoring process can connect to the gVisor sandbox and receive a stream of
|
||||
actions that the application is performing. The monitoring process decides what
|
||||
actions are allowed and what steps to take based on policies for the given
|
||||
|
||||
@@ -10,6 +10,8 @@ gVisor can do all packet processing internally and only has to enable a few host
|
||||
I/O syscalls for near-complete networking capabilities. This keeps gVisor’s
|
||||
exposure to host vulnerabilities as narrow as possible.
|
||||
|
||||
<!--/excerpt-->
|
||||
|
||||
Although writing Netstack in Go was important for runtime safety, up until now
|
||||
it had an undeniable performance cost. iperf benchmarks showed Netstack was
|
||||
spending between 20-30% of its processing time allocating memory and pausing for
|
||||
|
||||
@@ -6,7 +6,7 @@ virtualization. Unlike the ptrace platform, it’s fast 🚀. Go try it by addin
|
||||
`--platform=systrap` to the runsc flags. If you want to know more about it, read
|
||||
on.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
<!--/excerpt-->
|
||||
|
||||
gVisor is a security boundary for arbitrary Linux processes. Boundaries do not
|
||||
come for free, and gVisor imposes some performance overhead on sandboxed
|
||||
|
||||
@@ -6,7 +6,7 @@ a tmpfs filesystem. Learn more about this feature in the following blog that was
|
||||
[originally posted](https://opensource.googleblog.com/2023/04/gvisor-improves-performance-with-root-filesystem-overlay.html)
|
||||
on [Google Open Source Blog](https://opensource.googleblog.com/).
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
<!--/excerpt-->
|
||||
|
||||
## Costly Filesystem Access
|
||||
|
||||
|
||||
@@ -7,12 +7,13 @@ generate images using a GPU from within gVisor. Both the
|
||||
and the [PyTorch] code used by Stable Diffusion were run entirely within gVisor
|
||||
while being able to leverage the NVIDIA GPU.
|
||||
|
||||
<!--/excerpt-->
|
||||
|
||||

|
||||
<span class="attribution">**Sand**boxing a GPU. Generated with Stable Diffusion
|
||||
v1.5.<br/>This picture gets a lot deeper once you realize that GPUs are made out
|
||||
of sand.</span>
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
## Disclaimer
|
||||
|
||||
|
||||
@@ -7,7 +7,7 @@ the following blog that was
|
||||
[originally posted](https://opensource.googleblog.com/2023/06/optimizing-gvisor-filesystems-with-directfs.html)
|
||||
on [Google Open Source Blog](https://opensource.googleblog.com/).
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
<!--/excerpt-->
|
||||
|
||||
## Origins of the Gofer
|
||||
|
||||
|
||||
@@ -10,14 +10,14 @@ is actually executed. **This blog post contains more than you ever wanted to
|
||||
know about `seccomp-bpf`, and explores the past few months of work to optimize
|
||||
gVisor's use of it.**
|
||||
|
||||
<!--/excerpt-->
|
||||
|
||||
{:style="max-width:100%"}
|
||||
<span class="attribution">A diagram showing gVisor's two main layers of
|
||||
security: gVisor itself, and `seccomp-bpf`. This blog post touches on the
|
||||
`seccomp-bpf` part.
|
||||
[Tux logo by Larry Ewing and The GIMP](https://commons.wikimedia.org/wiki/File:Tux.svg).</span>
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
## Understanding `seccomp-bpf` performance in gVisor {#performance-considerations}
|
||||
|
||||
One challenge with gVisor performance improvement ideas is that it is often very
|
||||
|
||||
@@ -12,8 +12,8 @@ pagination:
|
||||
<div class="blog-meta">
|
||||
{% include byline.html authors=post.authors date=post.date %}
|
||||
</div>
|
||||
<p>{{ post.excerpt | strip_html }}</p>
|
||||
<p><a href="{{ post.url }}">Full Post »</a></p>
|
||||
<p>{{ post.excerpt }}</p>
|
||||
<p><a href="{{ post.url }}">Read more »</a></p>
|
||||
</div>
|
||||
{% endfor %}
|
||||
|
||||
|
||||
+2
-1
@@ -146,7 +146,8 @@ include_in_menu: {include_in_menu}"""
|
||||
builder_content.append("title=\"$(grep -E '^# ' %s | head -n 1 | cut -d'#' -f2- || true)\"" % f.path)
|
||||
builder_content.append("cat >$T/%s <<EOF" % dest)
|
||||
builder_content.append("---")
|
||||
builder_content.append("title: $title")
|
||||
builder_content.append("title: \"$title\"")
|
||||
builder_content.append("excerpt_separator: '<!--/excerpt-->'")
|
||||
builder_content.append(header.format(**args))
|
||||
builder_content.append("---")
|
||||
builder_content.append("EOF")
|
||||
|
||||
Reference in New Issue
Block a user