mirror of
https://github.com/linuxkit/linuxkit.git
synced 2026-04-04 18:59:55 +00:00
42b6b44fa9
...and add straw man implementations of kernel_config.base and kernel_config.x86 as examples. First, splitting the build: to avoid duplication, we split the build into three parts: a "source" stage, a "config" stage, and a "build" stage. The "source" stage allows us to use a cached image, so we don't have to re-download the kernel source every time. The "config" step applies our patches and generates (and checks) the kernel config. I've left this as a separate step for now so that we can build just an image with a config in it, without having to ^C the build. However there's no real reason it needs to be a separate step, assuming that this kernel config design is acceptable. The third step is the actual kernel build. Then there is kernel config management: the bulk of it occurs in makeconfig.sh, with the idea being that we can specify base, arch, and version specific config options as necessary. The config files themselves are lists of options (both positive and negative). We include the negative options, because we want to explicitly turn off things that are on in the default config (e.g. CONFIG_USELIB), and it seems cleaner to do things this way then to have some sort of negative options list. The options files are sorted with the default behavior of the "sort" command, which ignores comment lines, meaning that negative options and positive options are inline with each other. I don't have a strong opinion on whether or not to group all negative options, or whether this default behavior makes sense, so I just left it. Finally, obviously the .base and .x86 files are incomplete. I mostly selected a few options with interesting dependencies or special issues (CONFIG_PANIC_ON_OOPS) with how we manage things, so as to demo how everything would work. It's not really clear to me that there's a good way to generate e.g. kernel_config.base, without a lot of painstaking work (which I'm happy to do if we agree this is a good approach). Signed-off-by: Tycho Andersen <tycho@docker.com>
Projects
We aim to provide a set of open spaces for collaboration to help move projects towards production. Projects should usually
at a minimum provide a README of how to get started using the project with Moby, and a roadmap document explaining what
the aims are and how to contribute. Most projects will probably provide a way to run the project in a custom Moby build
in its current state, which ideally will be integrated in the Moby CI so there are checks that it builds and runs. Over
time we hope that many projects will graduate into the recommended production defaults, but other projects may remain as
ongoing projects, such as kernel hardening.
If you want to create a project, please submit a pull request to create a new directory here.
Current projects
- Kernel Self Protection Project enhancements
- Mirage SDK privilege separation for userspace services
- Wireguard cryptographic enforced container network separation
- OKernel intra-kernel protection using EPT (HPE)
- eBPF iovisor eBPF tools
- AWS AWS build support
- Swarmd Standalone swarmkit based orchestrator
- Landlock LSM programmatic access control
- Clear Containers Clear Containers image
- Logging Experimental logging tools
- etcd cluster etcd cluster demo from DockerCon'17
- kernel-config an experiment on how to manage kernel config
Current projects not yet documented
- VMWare support (VMWare)
- ARM port and secure boot integration (ARM)