This is the same as aufs variant, but without AUFS patches. Looks like
GCP may need this, at least initially.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
On older Windows builds (e.g. 10586) the 4.9.x TimeSync integration
service spams the logs with multiple messages a second of the form:
hv_utils: Using TimeSync version 4.0
It seems that a new protocol version was introduced with newer
Windows 10 builds but the kernel patches don't negotiate the
protocol version based on what the host supports, but instead
simply use the Windows version of the host.
Added two new patches:
- the first one is a cherry-pick from upstream which fixes some
of the TimeSync protocol negotiation, but does not fix the issue.
- the second one forces the TimeSync protocol to version 3.0 even on
Windows 10 hosts.
Patches based on: https://github.com/rneugeba/linux-stable/tree/v4.9.2-moby
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
As we released this in the beta channel, and it is a nice feature that our users love,
backporting this to 4.4 so we don't have to revert it or conditionally behave differently.
This is upstream Linux commits
- 9a08c352d05305ca7651540c3b107da1e4e1f40b fs: add filp_clone_open API
- 948b701a607f123df92ed29084413e5dd8cda2ed binfmt_misc: add persistent opened binary handler for containers
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
- Add back Linux kernel 4.4.x support, only for AUFS at present.
- Add back config options that are different for 4.4 series
See #923 for discussion on whether we need to do this.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
These headers are needed for defining kernel probes etc, tested with
eBPF. Could also be used for perf, building kernel modules etc. Saved
to the media tarball at present, may add to base image or container.
Also rationalise the paths in the headers tarball a little to match.
Will add an eBPF container using these later.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Saves passing too much context, less error prone and should
mean builds are faster if not clean, consistent with elsewhere.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Non AUFS kernels do not create `sbin/` and `/usr` directories as they
do not provide the AUFS directories. Just create empty directories to
avoid a warning.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Default config is restricted ptrace, processes can only ptrace
related processes, such as child processes, rather than any process
with the same uid.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
This seems the best option, although none are great
- build with `make AUFS=1` to build with AUFS support, currently with 4.8 kernel
- default is to build without AUFS support, with 4.9 kernel
This recognises that AUFS supprot is temporary #620 and only there until
we can phase it out on desktop editions, and allow the other editions that
never shipped with AUFS to ship something very close to mainline.
However we do still apply the patches so that the non AUFS branch runs fine on
all platforms, so it can be tested elsewhere.
We may be able to move the kernel versions back in line when 4.9 aufs support is out.
Plan is to shift CI to build both sets of images, and get the Desktop editions to
pick up the aufs set automatically, once this is merged.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
- The scanning process was not ignoring the kernel extraversion before,
so was only sometimes picking up issues.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Includes fix for CVE-2016-8655 Linux af_packet.c race condition.
This gives a container escape with default container capabilities.
This now has the slow network namespace patch backported, so this
is removed.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Regenerated the kernel config from container, which bumped the kernel
version and included some other fixes. Also bumps the check-config
container to check for VSYSCALL_NATIVE
Signed-off-by: Riyaz Faizullabhoy <riyaz.faizullabhoy@docker.com>
Some of git's whitespace fixup option corrupts the patches by (at least)
stripping trailing spaces (which are present for empty lines in context) and
changing leading <space><tab> into just <tab>. `patch(1)` used by the build
here seems to tolerate this, but `git am` and/or `git apply` do not.
Fix this up by running git am and at each failure point (i.e. every patch)
applying the relevant patch using `patch(1)` (which works because `git am` was
unable to even partially apply the patches) before regenerating the whole lot
with `git format-patch`.
Signed-off-by: Ian Campbell <ian.campbell@docker.com>
128 CPUs seems plenty for now and it allows for the
debug kernels to boot on Hyper-V without modifications. It may
also have the added benefit of reducing some data structures
allocated per CPU (in particular for Debug kernels).
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
