netbird/gvisor
0
0
Fork 0
mirror of https://github.com/netbirdio/gvisor.git synced 2026-05-22 17:12:49 -07:00
Code Issues Packages Projects Releases Wiki Activity

Added lint-md linter for markdown

Browse Source
This commit is contained in:
Ian Lewis
2019-10-24 02:35:07 -04:00
parent cf240fdf73
commit a7803353f0
18 changed files with 1225 additions and 111 deletions
Download Patch File Download Diff File Expand all files Collapse all files
Makefile
+10 -2
View File
@@ -10,6 +10,7 @@ GEN_SOURCE = $(wildcard cmd/generate-syscall-docs/*)
APP_SOURCE = $(wildcard cmd/gvisor-website/*)
# Target Go files, example: public/main.go, public/foo/bar.go.
APP_TARGET = $(patsubst cmd/gvisor-website/%,public/%,$(APP_SOURCE))
CONTENT_SOURCE = $(wildcard content/*)
default: website
.PHONY: default
@@ -63,10 +64,17 @@ compatibility-docs: bin/generate-syscall-docs upstream/gvisor/bazel-bin/runsc/li
./upstream/gvisor/bazel-bin/runsc/linux_amd64_pure_stripped/runsc help syscalls -o json | ./bin/generate-syscall-docs -out ./content/docs/user_guide/compatibility/
.PHONY: compatibility-docs
check: website
docker run -v $(shell pwd)/public:/public gcr.io/gvisor-website/html-proofer:3.10.2 htmlproofer --disable-external --check-html public/static
check: check-markdown check-html
.PHONY: check
check-markdown: node_modules $(CONTENT_SOURCE) compatibility-docs
npm run lint-md
.PHONY: check-markdown
check-html: website
docker run -v $(shell pwd)/public:/public gcr.io/gvisor-website/html-proofer:3.10.2 htmlproofer --disable-external --check-html public/static
.PHONY: check-html
# Run a local content development server. Redirects will not be supported.
devserver: all-upstream compatibility-docs
$(HUGO) server -FD --port 8080
cloudbuild.yaml
+4 -1
View File
@@ -49,7 +49,7 @@ steps:
- >
./upstream/gvisor/bazel-bin/runsc/linux_amd64_pure_stripped/runsc help syscalls -o json |
./bin/generate-syscall-docs -out ./content/docs/user_guide/compatibility/
# Pull npm dependencies for scss
# Pull npm dependencies for scss and lint-md
- name: 'gcr.io/cloud-builders/npm'
args: ['ci']
# Copy App Engine app files.
@@ -59,6 +59,9 @@ steps:
- name: 'gcr.io/gvisor-website/hugo:0.53'
env: ['HUGO_ENV=production']
args: ["hugo"]
# Test Markdown for issues.
- name: 'gcr.io/cloud-builders/npm'
args: ['run', 'lint-md']
# Test the HTML for issues.
- name: 'gcr.io/gvisor-website/html-proofer:3.10.2'
args:
content/docs/architecture_guide/_index.md
-2
View File
@@ -72,8 +72,6 @@ race detector. (The use of Go has its challenges too, and isn't free.)
[apparmor]: https://wiki.ubuntu.com/AppArmor
[golang]: https://golang.org
[kvm]: https://www.linux-kvm.org
[oci]: https://www.opencontainers.org
[sandbox]: https://en.wikipedia.org/wiki/Sandbox_(computer_security)
[seccomp]: https://www.kernel.org/doc/Documentation/prctl/seccomp_filter.txt
[selinux]: https://selinuxproject.org
[uml]: http://user-mode-linux.sourceforge.net/
content/docs/architecture_guide/overview.md
+3 -3
View File
@@ -8,12 +8,12 @@ be run.
Each sandbox has its own isolated instance of:
* The **Sentry**, A user-space kernel that runs the container and intercepts
and responds to system calls made by the application.
* The **Sentry**, A user-space kernel that runs the container and intercepts
and responds to system calls made by the application.
Each container running in the sandbox has its own isolated instance of:
* A **Gofer** which provides file system access to the container.
* A **Gofer** which provides file system access to the container.
![gVisor architecture diagram](../Sentry-Gofer.png "gVisor architecture diagram")
content/docs/architecture_guide/security.md
+12 -12
View File
@@ -32,9 +32,9 @@ are written in [C][clang], which is well-suited to interfacing with hardware but
often prone to security issues. In order to exploit these issues, a typical attack
might involve some combination of the following:
1. Opening or creating some combination of files, sockets or other descriptors.
1. Passing crafted, malicious arguments, structures or packets.
1. Racing with multiple threads in order to hit specific code paths.
1. Opening or creating some combination of files, sockets or other descriptors.
1. Passing crafted, malicious arguments, structures or packets.
1. Racing with multiple threads in order to hit specific code paths.
For example, for the [Dirty Cow][dirtycow] privilege escalation bug, an
application would open a specific file in `/proc` or use a specific `ptrace`
@@ -140,14 +140,14 @@ filesystem attributes) and not underlying host system resources.
While the sandbox virtualizes many operations for the application, we limit the
sandbox's own interactions with the host to the following high-level operations:
1. Communicate with a Gofer process via a connected socket. The sandbox may
1. Communicate with a Gofer process via a connected socket. The sandbox may
receive new file descriptors from the Gofer process, corresponding to opened
files. These files can then be read from and written to by the sandbox.
1. Make a minimal set of host system calls. The calls do not include the
1. Make a minimal set of host system calls. The calls do not include the
creation of new sockets (unless host networking mode is enabled) or opening
files. The calls include duplication and closing of file descriptors,
synchronization, timers and signal management.
1. Read and write packets to a virtual ethernet device. This is not required if
1. Read and write packets to a virtual ethernet device. This is not required if
host networking is enabled (or networking is disabled).
### System ABI, Side Channels and Other Vectors
@@ -173,17 +173,17 @@ less likely to exploit or override these controls through other means.
For gVisor development, there are several engineering principles that are
employed in order to ensure that the system meets its design goals.
1. No system call is passed through directly to the host. Every supported call
1. No system call is passed through directly to the host. Every supported call
has an independent implementation in the Sentry, that is unlikely to suffer
from identical vulnerabilities that may appear in the host. This has the
consequence that all kernel features used by applications require an
implementation within the Sentry.
1. Only common, universal functionality is implemented. Some filesystems,
1. Only common, universal functionality is implemented. Some filesystems,
network devices or modules may expose specialized functionality to user
space applications via mechanisms such as extended attributes, raw sockets
or ioctls. Since the Sentry is responsible for implementing the full system
call surface, we do not implement or pass through these specialized APIs.
1. The host surface exposed to the Sentry is minimized. While the system call
1. The host surface exposed to the Sentry is minimized. While the system call
surface is not trivial, it is explicitly enumerated and controlled. The
Sentry is not permitted to open new files, create new sockets or do many
other interesting things on the host.
@@ -191,11 +191,11 @@ employed in order to ensure that the system meets its design goals.
Additionally, we have practical restrictions that are imposed on the project to
minimize the risk of Sentry exploitability. For example:
1. Unsafe code is carefully controlled. All unsafe code is isolated in files
1. Unsafe code is carefully controlled. All unsafe code is isolated in files
that end with "unsafe.go", in order to facilitate validation and auditing.
No file without the unsafe suffix may import the unsafe package.
1. No CGo is allowed. The Sentry must be a pure Go binary.
1. External imports are not generally allowed within the core packages. Only
1. No CGo is allowed. The Sentry must be a pure Go binary.
1. External imports are not generally allowed within the core packages. Only
limited external imports are used within the setup code. The code available
inside the Sentry is carefully controlled, to ensure that the above rules
are effective.
content/docs/community/_index.md
+2 -2
View File
@@ -9,8 +9,8 @@ repositories have their own guidelines and processes for contributing. See the
The project maintains two mailing lists:
* [gvisor-users][gvisor-users] for accouncements and general discussion.
* [gvisor-dev][gvisor-dev] for development and contribution.
* [gvisor-users][gvisor-users] for accouncements and general discussion.
* [gvisor-dev][gvisor-dev] for development and contribution.
We also have a [chat room hosted on Gitter][gitter-chat].
content/docs/tutorials/docker.md
+1 -1
View File
@@ -59,7 +59,7 @@ docker run --runtime=runsc --name wordpress -d \
```
Now, you can access the WordPress website pointing your favorite browser to
http://localhost:8080.
<http://localhost:8080>.
Congratulations! You have just deployed a WordPress site using Docker.
content/docs/tutorials/kubernetes.md
+4 -4
View File
@@ -11,9 +11,9 @@ This page shows you how to deploy a sample [WordPress][wordpress] site using
Take the following steps to enable the Kubernetes Engine API:
1. Visit the [Kubernetes Engine page][project-selector] in the Google Cloud
Platform Console.
1. Create or select a project.
1. Visit the [Kubernetes Engine page][project-selector] in the Google Cloud
Platform Console.
1. Create or select a project.
### Creating a node pool with gVisor enabled
@@ -235,4 +235,4 @@ a look at the [documentation][gke-sandbox-docs].
[gke-sandbox-docs]: https://cloud.google.com/kubernetes-engine/docs/how-to/sandbox-pods
[gke-sandbox]: https://cloud.google.com/kubernetes-engine/sandbox/
[project-selector]: https://console.cloud.google.com/projectselector/kubernetes
[wordpress]: https://wordpress.com/
[wordpress]: https://wordpress.com/
content/docs/user_guide/FAQ.md
+6 -6
View File
@@ -89,12 +89,12 @@ order to communicate to the DNS server. runsc network is isolated from the
host and cannot access the DNS server on the host network without breaking the
sandbox isolation. There are a few different workarounds you can try:
* Use default bridge network with `--link` to connect containers. Default
bridge doesn't use embedded DNS.
* Use [`--network=host`][host-net] option in runsc, however beware that it will
use the host network stack and is less secure.
* Use IPs instead of container names.
* Use [Kubernetes][k8s]. Container name lookup works fine in Kubernetes.
* Use default bridge network with `--link` to connect containers. Default
bridge doesn't use embedded DNS.
* Use [`--network=host`][host-net] option in runsc, however beware that it will
use the host network stack and is less secure.
* Use IPs instead of container names.
* Use [Kubernetes][k8s]. Container name lookup works fine in Kubernetes.
[security-model]: /docs/architecture_guide/security/
[old-linux]: /docs/user_guide/networking/#gso
content/docs/user_guide/checkpoint_restore.md
+17 -17
View File
@@ -20,7 +20,7 @@ file will be called `checkpoint.img` and necessary directories will be created
if they do not yet exist.
> Note: Two checkpoints cannot be saved to the same directory; every image-path
provided must be unique.
> provided must be unique.
```bash
runsc checkpoint --image-path=<path> <container id>
@@ -31,11 +31,11 @@ continue to run after the checkpoint has been made. (By default, containers stop
their processes after committing a checkpoint.)
> Note: All top-level runsc flags needed when calling run must be provided to
checkpoint if --leave-running is used.
> checkpoint if --leave-running is used.
> Note: --leave-running functions by causing an immediate restore so the
container, although will maintain its given container id, may have a different
process id.
> container, although will maintain its given container id, may have a different
> process id.
```bash
runsc checkpoint --image-path=<path> --leave-running <container id>
@@ -83,19 +83,19 @@ docker start --checkpoint --checkpoint-dir=<directory> <container>
### Issues Preventing Compatibility with Docker
- **[Moby #37360][leave-running]:** Docker version 18.03.0-ce and earlier hangs
when checkpointing and does not create the checkpoint. To successfully use
this feature, install a custom version of docker-ce from the moby repository.
This issue is caused by an improper implementation of the `--leave-running`
flag. This issue is fixed in newer releases.
- **Docker does not support restoration into new containers:** Docker currently
expects the container which created the checkpoint to be the same container
used to restore which is not possible in runsc. When Docker supports container
migration and therefore restoration into new containers, this will be the
flow.
- **[Moby #37344][checkpoint-dir]:** Docker does not currently support the
`--checkpoint-dir` flag but this will be required when restoring from a
checkpoint made in another container.
* **[Moby #37360][leave-running]:** Docker version 18.03.0-ce and earlier hangs
when checkpointing and does not create the checkpoint. To successfully use
this feature, install a custom version of docker-ce from the moby repository.
This issue is caused by an improper implementation of the `--leave-running`
flag. This issue is fixed in newer releases.
* **Docker does not support restoration into new containers:** Docker currently
expects the container which created the checkpoint to be the same container
used to restore which is not possible in runsc. When Docker supports container
migration and therefore restoration into new containers, this will be the
flow.
* **[Moby #37344][checkpoint-dir]:** Docker does not currently support the
`--checkpoint-dir` flag but this will be required when restoring from a
checkpoint made in another container.
[leave-running]: https://github.com/moby/moby/pull/37360
[checkpoint-dir]: https://github.com/moby/moby/issues/37344
content/docs/user_guide/compatibility/_index.md
+4 -4
View File
@@ -40,10 +40,10 @@ The following applications/images have been tested:
Most common utilities work. Note that:
* Some tools, such as `tcpdump` and old versions of `ping`, require explicitly
enabling raw sockets via the unsafe `--net-raw` runsc flag.
* Different Docker images can behave differently. For example, Alpine Linux and
Ubuntu have different `ip` binaries.
* Some tools, such as `tcpdump` and old versions of `ping`, require explicitly
enabling raw sockets via the unsafe `--net-raw` runsc flag.
* Different Docker images can behave differently. For example, Alpine Linux and
Ubuntu have different `ip` binaries.
Specific tools include:
content/docs/user_guide/debugging.md
+4 -4
View File
@@ -106,9 +106,9 @@ Then restart docker to refresh the runtime options. While the container is runni
execute `runsc debug` to collect profile information and save to a file. Here are
the options available:
* **--profile-heap:** Generates heap profile to the speficied file.
* **--profile-cpu:** Enables CPU profiler, waits for `--profile-delay` seconds
and generates CPU profile to the speficied file.
* **--profile-heap:** Generates heap profile to the speficied file.
* **--profile-cpu:** Enables CPU profiler, waits for `--profile-delay` seconds
and generates CPU profile to the speficied file.
For example:
@@ -120,7 +120,7 @@ sudo runsc --root /var/run/docker/runtime-runsc-prof/moby debug --profile-heap=/
sudo runsc --root /var/run/docker/runtime-runsc-prof/moby debug --profile-cpu=/tmp/cpu.prof --profile-delay=30 63254c6ab3a6989623fa1fb53616951eed31ac605a2637bb9ddba5d8d404b35b
```
The resulting files can be opened using `go tool pprof` or [pprof]. The examples
The resulting files can be opened using `go tool pprof` or [pprof][pprof]. The examples
below create image file (`.svg`) with the heap profile and writes the top
functions using CPU to the console:
content/docs/user_guide/install.md
+4 -9
View File
@@ -87,10 +87,10 @@ curl -fsSL https://gvisor.dev/archive.key | sudo apt-key add -
Based on the release type, you will need to substitute `${DIST}` below, using
one of:
* `nightly`: For all nightly releases.
* `latest`: For the latest release.
* `${yyyymmdd}`: For specific releases.
* `${yyyymmdd}.${rc}`: For a specific point release.
* `nightly`: For all nightly releases.
* `latest`: For the latest release.
* `${yyyymmdd}`: For specific releases.
* `${yyyymmdd}.${rc}`: For a specific point release.
The repository for the release you wish to install should be added:
@@ -153,11 +153,6 @@ runsc install
```
[latest-nightly]: https://storage.googleapis.com/gvisor/releases/nightly/latest/runsc
[latest-hash]: https://storage.googleapis.com/gvisor/releases/nightly/latest/runsc.sha512
[oci]: https://www.opencontainers.org
[old-linux]: /docs/user_guide/networking/#gso
[releases]: https://github.com/google/gvisor/releases
content/docs/user_guide/platforms.md
+4 -4
View File
@@ -58,10 +58,10 @@ If you are using a virtual machine you will need to make sure that nested
virtualization is configured. Here are links to documents on how to set up
nested virtualization in several popular environments:
* Google Cloud: [Enabling Nested Virtualization for VM Instances][nested-gcp]
* Microsoft Azure: [How to enable nested virtualization in an Azure VM][nested-azure]
* VirtualBox: [Nested Virtualization][nested-virtualbox]
* KVM: [Nested Guests][nested-kvm]
* Google Cloud: [Enabling Nested Virtualization for VM Instances][nested-gcp]
* Microsoft Azure: [How to enable nested virtualization in an Azure VM][nested-azure]
* VirtualBox: [Nested Virtualization][nested-virtualbox]
* KVM: [Nested Guests][nested-kvm]
### Configuring Docker
content/docs/user_guide/quick_start/_index.md
+3 -3
View File
@@ -7,6 +7,6 @@ gVisor can be used with Docker, Kubernetes, or directly using `runsc` with
crafted OCI spec for your container. Use the links below to see detailed
instructions for each of them:
* [Docker](./docker/): The quickest and easiest way to get started.
* [Kubernetes](./kubernetes/): Isolate Pods in your K8s cluster with gVisor.
* [OCI](./oci/): Expert mode. Customize gVisor for your environment.
* [Docker](./docker/): The quickest and easiest way to get started.
* [Kubernetes](./kubernetes/): Isolate Pods in your K8s cluster with gVisor.
* [OCI](./oci/): Expert mode. Customize gVisor for your environment.
content/docs/user_guide/quick_start/kubernetes.md
+1 -1
View File
@@ -36,4 +36,4 @@ WordPress site. You can view the full documentation [here][gke-sandbox-docs].
[gke-sandbox-docs]: https://cloud.google.com/kubernetes-engine/docs/how-to/sandbox-pods
[gvisor-containerd-shim]: https://github.com/google/gvisor-containerd-shim
[runtimeclass]: https://kubernetes.io/docs/concepts/containers/runtime-class/
[wordpress-quick]: /docs/tutorials/kubernetes/
[wordpress-quick]: /docs/tutorials/kubernetes/
package-lock.json
Generated
+1130 -30
View File
File diff suppressed because it is too large Load Diff
package.json
+16 -6
View File
@@ -1,8 +1,18 @@
{
"name": "gvisor-website",
"version": "0.0.0",
"devDependencies": {
"autoprefixer": "^9.4.7",
"postcss-cli": "^6.1.1"
}
"name": "gvisor-website",
"version": "0.0.0",
"devDependencies": {
"autoprefixer": "^9.4.7",
"postcss-cli": "^6.1.1",
"remark-cli": "^7.0.0",
"remark-preset-lint-recommended": "^3.0.3"
},
"scripts": {
"lint-md": "remark ./content -f"
},
"remarkConfig": {
"plugins": [
"remark-preset-lint-recommended"
]
}
}