Re: [PATCH RFC 1/4] ipe: add the .ipe policy keyring

[Manuel Huber <manuelh@nvidia.com>]

On Mon, Oct 19, 2026 at 04:15:57PM -0700, Fan Wu wrote:
> You might need to explain why the existing keyrings, i.e.
> builtin/secondary/platform cannot be used in your scenario. Like the
> firmware is not trusted?

As touched upon in [1], the scenario uses an ephemeral VM whose
IEP policy would be assembled after boot. There is a mix of explicitly
trusted dm-verity root hashes and possibly signed dm-verity layers
which can vary per VM, so the final IPE policy would not necessarily
be known ahead of time.

This specific scenario is Kata Containers on Kubernetes. Each
Kubernetes pod runs in a headless Kata VM with a static dm-verity
protected rootfs, while its container image layers are delivered
dynamically as dm-verity protected block devices. The kata-agent acts
as trusted bootstrap userspace and would author the IPE policy for that
particular guest before starting its workload containers.

The firmware is trusted in this scenario. A public policy-signing
certificate could be compiled into the builtin keyring or provisioned
through the platform or secondary keyrings. Because the policy would be
authored inside the guest, however, the corresponding private key would
also have to be shipped as a static artifact in the guest rootfs and
shared by every guest using that build.

Instead, the kata-agent would generate an ephemeral, per-guest
policy-signing key pair, provision its public certificate, sign the
policy, destroy the private key, and restrict the keyring before
allowing untrusted code to execute.

A dedicated .ipe keyring thus provides a purpose-specific runtime
provisioning path for this scenario. Once the certificate has been
added, the keyring can be restricted against further enrollment.

I envision other scenarios with similar characteristics may benefit from
a dedicated .ipe keyring as well.

I could elaborate more on this, e.g., on the how users' deployed
container images translate to dm-verity protected image layers etc.
(the erofs snapshotter is used and there is no filesystem sharing
between host and guest, image layer transport is realized via block
device attachment), but I am trying to keep this response brief. Some
more breadcrumbs on the combination of containerd, IPE, Kata can be
found in [2] and [3].

[1] https://lore.kernel.org/r/SJ1PR12MB61246B0BF58BC2B6F0A79D30DE9F2@SJ1PR12MB6124.namprd12.prod.outlook.com
[2] https://github.com/containerd/containerd/issues/12081
[3] https://github.com/kata-containers/kata-containers/issues/10943