OCI Runtime Spec v1.1

Friday, July 21, 2023 by Open Container Initiative

We are delighted to annouce the release of the OCI Runtime Spec v1.1.0 today. This release contains about 80 pull requests that were merged in the last three years. We appreciate everybody who contributed to this release.

What is the OCI Runtime Spec?

The OCI Runtime Spec defines the behavior and the configuration interface of low-level container runtimes such as runc. The spec is also implemented by crun, youki, gVisor, Kata Containers, and others. These low-level container runtimes are usually called from high-level container runtimes such as containerd and CRI-O.

“Breaking” Changes

config: change prestart hook spec to match reality (#1169)

In the OCI Runtime Spec v1.0, prestart hooks were required to be called during the start operation. This was contrary to the actual implementation of runc, which calls prestart hooks as a part of the create operation. The spec was partially revised to fix this several years ago with the addition of new lifecycle hooks and the deprecation of the prestart hook but the text was confusing and didn’t full explain the correct recommendations for implementations.

The spec has now been revised to completely resolve this issue and make the (deprecated) prestart hook have the same behaviour as the actual runc implementation. Technically, this is a “breaking” change of the spec, but given that existing runtimes have already implemented this behaviour (even before the runtime-spec 1.0.0 release), and the specification already included text dealing with this issue we do not feel this warrants a major version bump.


The memory.kernel and memory.kernelTCP resource configurations are now marked as deprecated, as the upstream Linux kernel has deprecated the support for setting kernel memory limits since 5.4.

Note that runc has ignored these configuration settings since runc v1.0.0-rc94.


cgroup: add cgroup v2 support (#1040)

The spec now has the native support for cgroup v2. Implementations no longer need to “emulate” v1 configuration on v2 hosts.

This has been already implemented in runc since runc v1.0.0-rc93.

seccomp: support RISC-V 64 (#1059)

The spec now supports the RISC-V (riscv64) architecture.

runc supports RISC-V since runc v1.1.8.

seccomp: add Seccomp Notify support (#1074)

The spec now supports seccomp_unotify (since Linux kernel v5.0) to allow hooking syscalls from user-space. For example, this is useful for accelerating networking of rootless containers by hooking syscalls and replacing file descriptors from the host.

The support for seccomp_unotify has been already implemented in runc since runc v1.1.0-rc.1.

config: add IDMapping field for mount point (#1143)

The spec now supports ID-mapped mounts using MOUNT_ATTR_IDMAP (since Linux kernel v5.12). This eliminates the overhead of chown that was an obstacle to adopt user namespaces, though it should be noted that the rootfs cannot have idmapped mounts configured so higher-level runtimes will need to implement rootfs idmapping (which is fairly trivial).

This was recently implemented in the main branch of runc. Will be included in runc v1.2.0.

features: add features.md to formalize the runc features JSON (#1130)

runc features (since runc v1.1-rc.1) is a command that prints the information about the compiled-in features such as the recognized mount options and the recognized seccomp architectures.

The information structure is now officially part of the spec.

config-linux: add support for time namespace (#1151)

Time namespaces (since Linux kernel v5.6) allows isolating the CLOCK_MONOTONIC and the CLOCK_BOOTTIME clocks from the host and from other containers. This is especially useful for checkpointing with CRIU.

Note that the CLOCK_REALTIME clock (the best known Linux clock) is not isolated with time namespaces.

runc doesn’t implement time namespaces yet, but there is a pull request to implement it.

Other changes

See here for the list of the full changes.

“OCI 1.1”

Coincidentally, OCI Image Spec v1.1 and OCI Distribution Spec v1.1 are planned to be released soon too.

However, it should be noted that the specs are usually not intended to be released in ensemble. The next releases of the specs will be probably made separately.

What’s next?

See the GitHub issues and the pull requests for the proposals toward the future releases. e.g.,

You are always welcome to submit your own proposals too.