Re: [PATCH v2 1/3] ipe: add the .ipe policy keyring

[Fan Wu]

On Wed, Oct 28, 2026 at 5:31 PM Manuel Huber via B4 Relay
<devnull+manuelh.nvidia.com@xxxxxxxxxx> wrote:
>
> From: Manuel Huber <manuelh@xxxxxxxxxx>
>
> Add a dedicated .ipe keyring for IPE policy signature verification.
> With this, userspace can provision its own keys into the keyring,
> then restrict it and activate it for IPE policy signature verification.
>
> Gate creation of the keyring behind a new by-default disabled
> CONFIG_SECURITY_IPE_KEYRING Kconfig option. When created, the keyring
> is empty and writable. The keyring is used as a fallback after the
> existing policy trust sources only when it is created, non-empty, and
> restricted with restrict_link_reject.
>
> This enables scenarios in which a trusted userspace component generates
> an IPE policy, and creates an ephemeral policy-signing key pair,
> provisions its public certificate, and restricts the IPE keyring during
> the early lifetime of a system. The trusted component can then sign the
> IPE policy, destroy the private key, and load and activate the policy.
> During that phase, the system is considered in a trusted state whereas
> the system transitions into a possibly untrusted state afterwards,
> running arbitrary user-provided applications. In such a scenario, the
> trusted userspace component could reside on a dm-verity protected
> rootfs disk, and applications would reside on additional dm-verity
> protected disks. The latter disks would be dynamically attached and
> their dm-verity root hashes and/or signatures not known a priori to
> launching the system.
>
> A concrete usage scenario could be Kata Containers, which enables
> running Kubernetes pods in ephemeral, headless utility VMs, possibly
> without systemd. The rootfs disk is static and known beforehand, but
> containerd's image layers might be acquired and transported into the
> VM using the erofs snapshotter and dynamic block device attachment
> using dm-verity. While in that usage scenario, signing a per-guest
> policy with a pre-provisioned policy-signing certificate in the
> builtin, secondary, or platform keyrings would be technically possible,
> it would require including its corresponding private key in the guest
> build artifacts. Making it possible to use an ephemeral,
> userspace-provided key avoids shipping a static policy-signing private
> key with the guest rootfs.
>

Reading through this scenario again, I have a question about the design.

I suspect the reason you need a signing key inside the guest rootfs is
that you are running the snapshotter inside the VM. Have you
considered generating the snapshots on the VM host, signing the policy
there, and passing it into the guest?

The workflow would be:

1. The host generates an ephemeral signing key pair for the VM and
injects the public certificate into the guest's platform keyring via
firmware.
2. The host prepares the image snapshots, computes their dm-verity
root hashes, and signs the resulting IPE policy which allows execution
by dm-verity root hash with the ephemeral private key.
3. The host attaches the snapshot block devices and passes the signed
policy into the guest, where the guest simply loads and activates it
against .platform.

That way no private key ever needs to live in the guest, and it
confines the TCB to the VM host. Would this approach work for your
setup?

Fan