- Update to packages using the Alpine 3.6 base image
- Remove config for packages which now supply it
- Update/add trust section
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
The latest version of the `moby` tool now requires that the output formats
be specified in the CLI not in the yaml file.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
The kernel configs themselves are stored as diffs of what we want vs. each
version's defconfig.
Thus, things like e.g. CONFIG_DEVKMEM drop out after it was made
non-default. The implication of this is (I hope) that as upstream adopts
security features, our delta can shrink (or more realistically, only
include the next-next gen features).
Signed-off-by: Tycho Andersen <tycho@docker.com>
This is the script I used with [1] to generate the config diffs and
separate out the arch specific bits. Included mostly just so people can
play around with it if they want to generate their own diffs.
[1]: https://github.com/ulfalizer/Kconfiglib
Signed-off-by: Tycho Andersen <tycho@docker.com>
In particular, let's start with a defconfig and edit it, rather than try to
generate the config entirely from our own diff.
Signed-off-by: Tycho Andersen <tycho@docker.com>
Since containers are spawned by containerd (which is in the host PID namespace)
and not in the swarmd container's namespace.
Signed-off-by: Ian Campbell <ian.campbell@docker.com>
Note these are only the ones using the `containerd` based `init` as
the `runc` ones are still using an old one.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
...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>
This is just a direct import of the current kernel/ directory, with a
slight splitting up of the dockerfiles to build a kernel-source and kernel
image.
Signed-off-by: Tycho Andersen <tycho@docker.com>
Drop `hyperkit` from the `linuxkit run` invocation, thus causing the linuxkit
tool to pick the platform's default backend (which is qemu on my Linux system,
which works better than hyperkit in this environment).
Signed-off-by: Ian Campbell <ian.campbell@docker.com>
