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

[Fan Wu]

On Thu, Oct 22, 2026 at 11:02 AM Manuel Huber <manuelh at nvidia.com> wrote:
>
> 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

Thanks for the explanation. This clarifies a lot. Please include this
context in the commit message and doc for v2.

Also, one thing I missed earlier: before the policy verification call,
please also check:

ipe_keyring->restrict_link->check == restrict_link_reject

so we make sure the restriction function is the right one.

Fan