Merge pull request #1373 from avsm/okernel

kernel: add build config for the experimental "split kernel"

projects/okernel/Dockerfile.okernel

@@ -0,0 +1,55 @@
+FROM mobylinux/alpine-build-kernel:0e893fbf6fa7638d2f23354de03ea11017bb8065@sha256:3ef3f9d11f0802b759dbd9c43a7706cf0ec37263c99ae90e2b10c29ea85739fa
+
+ARG KERNEL_PREFIX
+ARG KERNEL_VERSION
+ARG DEBUG=0
+
+ENV KERNEL_SOURCE=https://github.com/linux-okernel/linux-okernel/archive/ok-${KERNEL_VERSION}.tar.gz
+
+RUN curl -fsSL -o linux-${KERNEL_PREFIX}${KERNEL_VERSION}.tar.gz ${KERNEL_SOURCE}
+
+RUN cat linux-${KERNEL_PREFIX}${KERNEL_VERSION}.tar.gz | tar --absolute-names -xz &&  mv /linux-${KERNEL_PREFIX}${KERNEL_VERSION} /linux
+
+# NOTE: This currently re-uses the 4.9 kernel config with CONFIG_OKERNEL set
+COPY kernel_config.okernel /linux/arch/x86/configs/x86_64_defconfig
+#COPY kernel_config.debug /linux/debug_config
+
+RUN if [ $DEBUG -ne "0" ]; then \
+    sed -i 's/CONFIG_PANIC_ON_OOPS=y/# CONFIG_PANIC_ON_OOPS is not set/' /linux/arch/x86/configs/x86_64_defconfig; \
+    cat /linux/debug_config >> /linux/arch/x86/configs/x86_64_defconfig; \
+    fi
+
+# Apply local patches
+# COPY patches-4.10 /patches
+#RUN cd /linux && \
+#   set -e && for patch in /patches/*.patch; do \
+#        echo "Applying $patch"; \
+#        patch -p1 < "$patch"; \
+#    done
+
+RUN cd /linux && \
+    make defconfig && \
+    make oldconfig && \
+    make -j "$(getconf _NPROCESSORS_ONLN)" KCFLAGS="-fno-pie"
+RUN cd /linux && \
+    make INSTALL_MOD_PATH=/tmp/kernel-modules modules_install && \
+    ( DVER=$(basename $(find /tmp/kernel-modules/lib/modules/ -mindepth 1 -maxdepth 1)) && \
+      cd /tmp/kernel-modules/lib/modules/$DVER && \
+      rm build source && \
+      ln -s /usr/src/linux-headers-$DVER build ) && \
+    mkdir -p /tmp/kernel-headers/usr && \
+    make INSTALL_HDR_PATH=/tmp/kernel-headers/usr headers_install && \
+    ( cd /tmp/kernel-headers && tar cf /kernel-headers.tar usr ) && \
+    ( cd /tmp/kernel-modules && tar cf /kernel-modules.tar lib ) && \
+    cp vmlinux arch/x86_64/boot/bzImage /
+
+RUN DVER=$(basename $(find /tmp/kernel-modules/lib/modules/ -mindepth 1 -maxdepth 1)) && \
+    dir=/tmp/usr/src/linux-headers-$DVER && \
+    mkdir -p $dir && \
+    cp /linux/.config $dir && \
+    cd /linux && \
+    cp -a include "$dir" && \
+    mkdir -p "$dir"/arch/x86 && cp -a arch/x86/include "$dir"/arch/x86/ && \
+    ( cd /tmp && tar cf /kernel-dev.tar usr/src )
+
+RUN printf "KERNEL_SOURCE=${KERNEL_SOURCE}\n" > /kernel-source-info

projects/okernel/Makefile

@@ -0,0 +1,84 @@
+DEBUG ?= 0
+
+all:	bzImage tag
+
+# We push the image to hub twice, once with the full kernel version of
+# "mobylinux/kernel:<kernel version>.<major version>.<minor version>-<n>",
+# where "<n>" is a monotonically increasing config number, and as
+# "mobylinux/kernel:<kernel version>.<major version>.x". This version
+# number is stored in IMAGE_VERSION.
+#
+# We expect most users to us the "<kernel version>.<major version>.x"
+# variant as this simply is the latest version of a given major kernel
+# version. This version number is stored in IMAGE_MAJOR_VERSION.
+#
+# For IMAGE_VERSION, the "<n>" must be increased whenever
+# the kernel config or the patches change. We don't expect this to
+# happen very often as the minor version number gets update quite
+# frequently.
+#
+# IMAGE_VERSION is used to determine if a new image should be pushed to hub.
+ifeq ($(KERNEL),v4.4)
+KERNEL_VERSION=4.4.56
+IMAGE_VERSION=$(KERNEL_VERSION)-0
+IMAGE_MAJOR_VERSION=4.4.x
+DEPS=Dockerfile.4.4 Makefile kernel_config kernel_config.debug kernel_config.4.4 patches-4.4
+else
+ifeq ($(KERNEL),v4.10)
+KERNEL_VERSION=4.10.5
+IMAGE_VERSION=$(KERNEL_VERSION)-0
+IMAGE_MAJOR_VERSION=4.10.x
+DEPS=Dockerfile.4.10 Makefile kernel_config kernel_config.debug patches-4.10
+else
+KERNEL_VERSION=4.9.17
+IMAGE_VERSION=$(KERNEL_VERSION)-0
+IMAGE_MAJOR_VERSION=4.9.x
+DEPS=Dockerfile Makefile kernel_config kernel_config.debug patches-4.9
+endif
+endif
+
+kernel.tag: $(DEPS)
+	BUILD=$$( tar cf - $^ | docker build -f $< --build-arg DEBUG=$(DEBUG) --build-arg KERNEL_VERSION=$(KERNEL_VERSION) -q - ) && [ -n "$$BUILD" ] && echo "Built $$BUILD" && echo "$$BUILD" > $@
+
+bzImage: kernel.tag
+	rm -rf etc/kernel-patches
+	mkdir -p x86_64 etc lib usr sbin etc/kernel-patches
+	docker run --rm --net=none --log-driver=none $(shell cat kernel.tag) tar cf - bzImage kernel-dev.tar kernel-headers.tar vmlinux kernel-modules.tar | tar xf - -C x86_64
+	cp x86_64/kernel-modules.tar kernel.tar
+	cp x86_64/bzImage $@
+
+.PHONY: image push tag
+
+MEDIA_TOYBOX=mobylinux/toybox-media:0a26fe5f574e444849983f9c4148ef74b3804d55@sha256:5ac38f77b66deb194c9016591b9b096e81fcdc9f7c3e6d01566294a6b4b4ebd2
+
+BASE="$MEDIA_TOYBOX"
+IMAGE=kernel
+
+default: push
+
+Dockerfile.media:
+	printf "FROM $(MEDIA_TOYBOX)\nADD . /\n" > $@
+
+image: Dockerfile.media bzImage kernel.tar $(DEPS)
+	tar cf - $^ | docker build --no-cache -t $(IMAGE):build -f Dockerfile.media -
+
+push: image
+	docker pull mobylinux/$(IMAGE):$(IMAGE_VERSION) || \
+		(docker tag $(IMAGE):build mobylinux/$(IMAGE):$(IMAGE_VERSION) && \
+		 docker push mobylinux/$(IMAGE):$(IMAGE_VERSION) && \
+		 docker tag $(IMAGE):build mobylinux/$(IMAGE):$(IMAGE_MAJOR_VERSION) && \
+		 docker push mobylinux/$(IMAGE):$(IMAGE_MAJOR_VERSION))
+	docker rmi $(IMAGE):build
+	rm -f hash
+
+tag: image
+	(docker tag $(IMAGE):build mobylinux/$(IMAGE):$(IMAGE_VERSION) && \
+	docker tag $(IMAGE):build mobylinux/$(IMAGE):$(IMAGE_MAJOR_VERSION))
+	docker rmi $(IMAGE):build
+	rm -f hash
+
+.PHONY: clean
+clean:
+	rm -rf x86_64 lib usr sbin kernel.tag Dockerfile.media bzImage kernel.tar
+
+.DELETE_ON_ERROR:

projects/okernel/README.md

@@ -1,6 +1,6 @@
 Authors: Chris Dalton <cid@hpi.com>, Nigel Edwards <nigel.edwards@hpe.com>
 
-Split Kernel
+# Split Kernel
 
 Similar to the nested-kernel work for BSD by Dautenhan[1], the aim of
 the split kernel is to introduce a level of intra-kernel protection
@@ -64,8 +64,7 @@ conflict with permissions in the lower-level page tables, a VMEXIT (in
 the current prototype which uses Intel VMX) is triggered. R-mode is
 then entered where will handle the permission violation.
 
-
+# Limitations and Caveats
-LIMITATIONS AND CAVEATS
 
 The current implementation does not have any protection of the kernel
 in place yet. It is a demonstration that you can create processes run
@@ -83,16 +82,14 @@ are:
  - Protection of kernel executable code RX only
  - Protection of kernel data structures RO
 
+# References
 
-REFERENCES:
+- [1] Nested Kernel: An Operating System Architecture for Intra-Kernel
-
-[1] Nested Kernel: An Operating System Architecture for Intra-Kernel
 Privilege Separation, Nathan Dautenhahn, Theodoros Kasampalis, Will
 Dietz, John Criswell, Vikram Adve, ASPLOS '15, Proceedings of the
 Twentieth International Conference on Architectural Support for
 Programming Languages and Operating Systems, March 2015.
-
+- [2] Dune: Safe user-level access to privileged CPU features, Adam
-[2] Dune: Safe user-level access to privileged CPU features, Adam
 Belay, Andrea Bittau, Ali Mashtizadeh, David Terei, David Mazières,
 and Christos Kozyrakis, OSDI '12, Proceedings of the 10th USENIX
 Symposium on Operating Systems Design and Implementation, October