*scratch*

it happened a few times in the past that users wonder why they see two /sys/fs/cgroup mounts in their unprivileged container.

I have been working on a new functionality for the prctl syscall utility that addresses a common security concern with container runtimes.

When I've started working on crun, I was looking at a faster way to start up and stop containers by improving the OCI runtime, the component in the OCI stack that is responsible to ultimately talk to the kernel and setting the environment where the container runs.

an interesting issue was opened for crun a couple of days ago.

For the last couple of weeks, I've been playing on PoC implementation of a file system for the Linux kernel.

seccomp is a kernel feature that restricts what syscalls can be used by a process.

Almost every container runs with seccomp enabled to restrict its access to syscalls.

One annoying issue with setting a memory limit for a container is that the OOM killer kernel process can leave the container in an inconsistent state with only some processes terminated.

A couple weekends ago I've played with seccomp user notifications and how they can be used in the OCI containers stack.

Seccomp user notifications are a powerful Linux kernel feature, that delegates syscalls handling to a userland program.

While working on crun, I got surprised by how much time the kernel spent in the copy_mount_options function.

CRFS is a Google project that aims at running a container without pre-pulling the image first.