f7b3eb38ef
This skips 0.0.20190531
Changelog for 0.0.20190601
== Changes ==
* compat: don't call xgetbv on cpus with no XSAVE
There was an issue with the backport compat layer in yesterday's snapshot,
causing issues on certain (mostly Atom) Intel chips on kernels older than
4.2, due to the use of xgetbv without checking cpu flags for xsave support.
This manifested itself simply at module load time. Indeed it's somewhat tricky
to support 33 different kernel versions (3.10+), plus weird distro
frankenkernels.
Changelog for 0.0.20190531
== Changes ==
* tools: add wincompat layer to wg(8)
Consistent with a lot of the Windows work we've been doing this last cycle,
wg(8) now supports the WireGuard for Windows app by talking through a named
pipe. You can compile this as `PLATFORM=windows make -C src/tools` with mingw.
Because programming things for Windows is pretty ugly, we've done this via a
separate standalone wincompat layer, so that we don't pollute our pretty *nix
utility.
* compat: udp_tunnel: force cast sk_data_ready
This is a hack to work around broken Android kernel wrapper scripts.
* wg-quick: freebsd: workaround SIOCGIFSTATUS race in FreeBSD kernel
FreeBSD had a number of kernel race conditions, some of which we can vaguely
work around. These are in the process of being fixed upstream, but probably
people won't update for a while.
* wg-quick: make darwin and freebsd path search strict like linux
Correctness.
* socket: set ignore_df=1 on xmit
This was intended from early on but didn't work on IPv6 without the ignore_df
flag. It allows sending fragments over IPv6.
* qemu: use newer iproute2 and kernel
* qemu: build iproute2 with libmnl support
* qemu: do not check for alignment with ubsan
The QEMU build system has been improved to compile newer versions. Linking
against libmnl gives us better error messages. As well, enabling the alignment
check on x86 UBSAN isn't realistic.
* wg-quick: look up existing routes properly
* wg-quick: specify protocol to ip(8), because of inconsistencies
The route inclusion check was wrong prior, and Linux 5.1 made it break
entirely. This makes a better invocation of `ip route show match`.
* netlink: use new strict length types in policy for 5.2
* kbuild: account for recent upstream changes
* zinc: arm64: use cpu_get_elf_hwcap accessor for 5.2
The usual churn of changes required for the upcoming 5.2.
* timers: add jitter on ack failure reinitiation
Correctness tweak in the timer system.
* blake2s,chacha: latency tweak
* blake2s: shorten ssse3 loop
In every odd-numbered round, instead of operating over the state
x00 x01 x02 x03
x05 x06 x07 x04
x10 x11 x08 x09
x15 x12 x13 x14
we operate over the rotated state
x03 x00 x01 x02
x04 x05 x06 x07
x09 x10 x11 x08
x14 x15 x12 x13
The advantage here is that this requires no changes to the 'x04 x05 x06 x07'
row, which is in the critical path. This results in a noticeable latency
improvement of roughly R cycles, for R diagonal rounds in the primitive. As
well, the blake2s AVX implementation is now SSSE3 and considerably shorter.
* tools: allow setting WG_ENDPOINT_RESOLUTION_RETRIES
System integrators can now specify things like
WG_ENDPOINT_RESOLUTION_RETRIES=infinity when building wg(8)-based init
scripts and services, or 0, or any other integer.
Signed-off-by: Rolf Neugebauer <rn@rneugeba.io>
|
||
|---|---|---|
| .circleci | ||
| .github | ||
| contrib | ||
| docs | ||
| examples | ||
| kernel | ||
| logo | ||
| pkg | ||
| projects | ||
| reports | ||
| scripts | ||
| sigs | ||
| src/cmd/linuxkit | ||
| test | ||
| tools | ||
| .gitattributes | ||
| .gitignore | ||
| .mailmap | ||
| ADOPTERS.md | ||
| AUTHORS | ||
| CHANGELOG.md | ||
| CONTRIBUTING.md | ||
| LICENSE | ||
| linuxkit.yml | ||
| MAINTAINERS | ||
| Makefile | ||
| NOTICE | ||
| poule.yml | ||
| README.md | ||
LinuxKit
LinuxKit, a toolkit for building custom minimal, immutable Linux distributions.
- Secure defaults without compromising usability
- Everything is replaceable and customisable
- Immutable infrastructure applied to building Linux distributions
- Completely stateless, but persistent storage can be attached
- Easy tooling, with easy iteration
- Built with containers, for running containers
- Designed to create reproducible builds [WIP]
- Designed for building and running clustered applications, including but not limited to container orchestration such as Docker or Kubernetes
- Designed from the experience of building Docker Editions, but redesigned as a general-purpose toolkit
- Designed to be managed by external tooling, such as Infrakit or similar tools
- Includes a set of longer-term collaborative projects in various stages of development to innovate on kernel and userspace changes, particularly around security
LinuxKit currently supports the x86_64, arm64, and s390x architectures on a variety of platforms, both as virtual machines and baremetal (see below for details).
Subprojects
- LinuxKit kubernetes aims to build minimal and immutable Kubernetes images. (previously
projects/kubernetesin this repository). - LinuxKit LCOW LinuxKit images and utilities for Microsoft's Linux Containers on Windows.
- linux A copy of the Linux stable tree with branches LinuxKit kernels.
- virtsock A
golibrary and test utilities forvirtioand Hyper-V sockets. - rtf A regression test framework used for the LinuxKit CI tests (and other projects).
- homebrew Homebrew packages for the
linuxkittool.
Getting Started
Build the linuxkit tool
LinuxKit uses the linuxkit tool for building, pushing and running VM images.
Simple build instructions: use make to build. This will build the tool in bin/. Add this
to your PATH or copy it to somewhere in your PATH eg sudo cp bin/* /usr/local/bin/. Or you can use sudo make install.
If you already have go installed you can use go get -u github.com/linuxkit/linuxkit/src/cmd/linuxkit to install the linuxkit tool.
On MacOS there is a brew tap available. Detailed instructions are at linuxkit/homebrew-linuxkit,
the short summary is
brew tap linuxkit/linuxkit
brew install --HEAD linuxkit
Build requirements from source:
- GNU
make - Docker
- optionally
qemu
Building images
Once you have built the tool, use
linuxkit build linuxkit.yml
to build the example configuration. You can also specify different output formats, eg linuxkit build -format raw-bios linuxkit.yml to
output a raw BIOS bootable disk image, or linuxkit build -format iso-efi linuxkit.yml to output an EFI bootable ISO image. See linuxkit build -help for more information.
Booting and Testing
You can use linuxkit run <name> or linuxkit run <name>.<format> to
execute the image you created with linuxkit build <name>.yml. This
will use a suitable backend for your platform or you can choose one,
for example VMWare. See linuxkit run --help.
Currently supported platforms are:
- Local hypervisors
- HyperKit (macOS)
[x86_64] - Hyper-V (Windows)
[x86_64] - qemu (macOS, Linux, Windows)
[x86_64, arm64, s390x] - VMware (macOS, Windows)
[x86_64]
- HyperKit (macOS)
- Cloud based platforms:
- Amazon Web Services
[x86_64] - Google Cloud
[x86_64] - Microsoft Azure
[x86_64] - OpenStack
[x86_64]
- Amazon Web Services
- Baremetal:
- packet.net
[x86_64, arm64] - Raspberry Pi Model 3b
[arm64]
- packet.net
Running the Tests
The test suite uses rtf To
install this you should use make bin/rtf && make install. You will
also need to install expect on your system as some tests use it.
To run the test suite:
cd test
rtf -v run -x
This will run the tests and put the results in a the _results directory!
Run control is handled using labels and with pattern matching. To run add a label you may use:
rtf -v -l slow run -x
To run tests that match the pattern linuxkit.examples you would use the following command:
rtf -v run -x linuxkit.examples
Building your own customised image
To customise, copy or modify the linuxkit.yml to your own file.yml or use one of the examples and then run linuxkit build file.yml to
generate its specified output. You can run the output with linuxkit run file.
The yaml file specifies a kernel and base init system, a set of containers that are built into the generated image and started at boot time. You can specify the type
of artifact to build eg linuxkit build -format vhd linuxkit.yml.
If you want to build your own packages, see this document.
Yaml Specification
The yaml format specifies the image to be built:
kernelspecifies a kernel Docker image, containing a kernel and a filesystem tarball, eg containing modules. The example kernels are built fromkernel/initis the baseinitprocess Docker image, which is unpacked as the base system, containinginit,containerd,runcand a few tools. Built frompkg/init/onbootare the system containers, executed sequentially in order. They should terminate quickly when done.servicesis the system services, which normally run for the whole time the system is upfilesare additional files to add to the image
For a more detailed overview of the options see yaml documentation
Architecture and security
There is an overview of the architecture covering how the system works.
There is an overview of the security considerations and direction covering the security design of the system.
Roadmap
This project was extensively reworked from the code we are shipping in Docker Editions, and the result is not yet production quality. The plan is to return to production quality during Q3 2017, and rebase the Docker Editions on this open source project during this quarter. We plan to start making stable releases on this timescale.
This is an open project without fixed judgements, open to the community to set the direction. The guiding principles are:
- Security informs design
- Infrastructure as code: immutable, manageable with code
- Sensible, secure, and well-tested defaults
- An open, pluggable platform for diverse use cases
- Easy to use and participate in the project
- Built with containers, for portability and reproducibility
- Run with system containers, for isolation and extensibility
- A base for robust products
Development reports
There are monthly development reports summarising the work carried out each month.
Adopters
We maintain an incomplete list of adopters. Please open a PR if you are using LinuxKit in production or in your project, or both.
FAQ
See FAQ.
Released under the Apache 2.0 license.