On Mon, Oct 12, 2026 at 03:12:53PM +0200, Christian Brauner wrote: > I think another keyring for just .ipe is fine if they want that. I > wonder what you use ipe for. I've implemented ipe via a simple bpf lsm > in userspace (well, for dm-verity. We don't use IMA or fsverity.). It's > available in systemd itself.
Thanks, Christian, for bringing this onto my radar. Initially, I was only seeking input on how to address David Howells' point about the one-off sequence for assigning key IDs for the case I would introduce a new IPE keyring (i.e. whether to use -12 and continue with the existing pattern under question or to shift to introducing a dedicated key range such as -257..-512). However, the excellent point you're raising may indeed possibly allow me to achieve my goals without leveraging IPE at all, building a BPF based mechanism instead. My scenario: Kata Containers runs Kubernetes pods in ephemeral, headless VMs. When pods are scheduled via kubelet, containerd, and the Kata shim on the host cause a pod VM to be launched inside which the Kata agent creates and runs the workload containers. The Kata stack has various flavor variants. The variant I am trying to harden is disabling filesystem sharing between host and guest VM and cold-plugging rootfs disk(s) for the guest VM at launch time (Kata agent sits in the rootfs). These disks are dm-verity protected; the kernel directly boots into the rootfs without an initramfs using verity kernel command line parameters. In systemd-less Kata flavors, Kata agent runs as the initial process, and waits for CreateContainer requests. Creating and starting containers requires a transport for container image layers from host to guest. This variant uses containerd's erofs snapshotter which provides dm-verity protected image layers. The Kata shim hot-plugs these image layers as a single block device (VMDK+GPT). Today, the kata-agent mounts each layer found in that disk using dm-verity. My goal is to enforce strict code integrity for these guests, and that can be achieved because all code we expect to be executed resides on dm-verity protected r/o mounts. Obviously, this requires users to be aware that they can no longer dynamically acquire code and run it from a tmpfs. My idea so far was to leverage IPE to enforce code integrity. However, the current IPE model does not yet apply well for my scenario, mainly because the container image layer root hashes (and their signatures) to be used are not known ahead of time, so I cannot bake in a static IPE policy. The idea was thus to allow trusted userspace to provision an IPE policy. For this, kata-agent would dynamically create a key pair. Before starting workloads (and thus transitioning to an untrusted state), kata-agent would populate and restrict the IPE keyring, author, sign, load and enforce the IPE policy. At this point in time, all dm-verity devices are mounted. For this, the first step would be to establish the IPE keyring. I was additionally going to introduce a 'sealing' mechanism for IPE as a separate contribution: right before kata-agent starts the workload containers, the agent seals the IPE policy. I was going to express this within IPE itself, blocking alterations to the IPE policy via securityfs. The sealing would be expressed via IPE policy definitions, e.g., "op=IPE_ENFORCEMENT_OFF action=DENY", or "op=IPE_POLICY_UPDATE action=DENY", so this way not even a privileged workload with CAP_MAC_ADMIN would be able to tamper with the policy. This was a brief as possible explanation, may lack context and details, but I hope the general idea made sense.
