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

[Christian Brauner]

On Wed, Oct 21, 2026 at 12:51:35PM -0400, Paul Moore wrote:
> Just a quick point of clarification, you're using the pattern you
> described for other keyrings, not necessarily a dedicated IPE keyring
> described in this patchset, correct?

Correct. The .dm-verity keyring and the .bpf keyring both work like
this: sealed empty by default, opened for a single boot via a kernel
parameter, and only ever consulted once the keyring is non-empty and
restricted. Manuel modeled the .ipe keyring on them after talking to
Fan.

> I know you/Lennart/systemd made the decision to implement your own
> version of IPE instead of working with Fan to augment the existing
> implementation to meet your needs, so I'm not sure if you've also done
> something with an out-of-tree patch, BPF, etc. to implement your own
> keyring.

There is no out-of-tree anything and there is no keyring of our own.

RestrictFileSystemAccess= is a BPF LSM program that PID 1 loads. It
denies exec, executable mappings and W^X transitions for anything that
isn't on a signed dm-verity device or the initramfs. That's it. It
uses the hooks BPF LSM exposes.

> As far as I'm concerned the decision of how IPE uses an IPE keyring is
> up to Fan.

This is really not an argument. Manuel posted an RFC that follows two
existing in-tree keyrings to the letter. Fan asked to deviate from them.
I explained what that costs.

> Of course, fitting in with existing norms is important,
> but if it causes IPE or existing IPE uses a lot of pain, that can a
> good reason to diverge from those solutions.

Which pain? The keyring is dead unless the kernel command line opens
it, and it is only consulted after the system keyrings have already
rejected the signature. Existing IPE users see no change whatsoever.

Fan's reasons were that it "looks kind of awkward" and that fs-verity
does it differently. I haven't yet heard a single technical reason to
deviate. The properties we get and the other model loses are:

(1) Fail closed by default. Without the boot parameter the keyring is
    sealed empty for the whole boot and can never be provisioned. With
    the fs-verity model the keyring is open on every kernel that has
    it and stays open until someone remembers to restrict it. If
    nobody does, root in the "untrusted" phase enrolls its own cert
    and loads its own policy.

(2) The opt-in is per boot and lives on the kernel command line, i.e.
    in the measured/signed boot chain. A Kconfig knob can't express
    "this boot", only "this kernel", and a distro kernel with the
    option on is simply open everywhere.

(3) Activation is tied to restriction. The keyring is only consulted
    once it can't be extended anymore, so there is never a window
    where a half-provisioned keyring is a trust anchor. With the
    fs-verity model it is a trust anchor from the first key on and
    extensible until sealed.

(4) That's what gives Manuel's Kata case the throwaway key: generate
    an ephemeral key pair, enroll the cert, restrict, sign the policy,
    load it, destroy the private key. After that nothing can be added
    to the keyring and nothing new can be signed. With the fs-verity
    model the same sequence leaves the keyring extensible unless the
    agent also seals, and the kernel doesn't care whether it did.

Note that IPE's own CI already does padd followed by restrict_keyring
on .fs-verity in the initrd (anchor-fsverity.service). So IPE relies
on exactly this sequence today. The pattern just has the kernel
enforce it instead of hoping that userspace gets it right.

So what does IPE gain from a keyring that is open by default and
consulted before it's sealed?

> These days everyone is
> going to implement whatever they please, but if you have
> needs/requirements about how you want things to behave in LSM land, I
> think it would be helpful to engage with us before you make a decision
> and then start pleading with the LSM folks to adopt your approach.

I'm not pleading with anyone. And the engagement you're asking for
happened. You just didn't engage:

- You read Daniel's bpf keyring series yourself in August, Cc'd the
  keyring folks "for obvious reasons", and had nothing to say about
  the model. The cover letter spelled out in detail that systemd would
  provision that keyring the same way as .dm-verity.

- On 2026-10-11 Manuel announced in the KEY_SPEC thread that he'd
  propose a .ipe keyring "modeled after the .dm-verity keyring" after
  "initial discussions with Fan Wu". You and linux-security-module
  were on Cc.

As for "everyone is going to implement whatever they please"... In May
you told the bpf folks that "we just need to be willing to accept that
we have different needs and show a willingness to accept different
solutions as a result" [1]. I don't see why that shouldn't apply to
systemd using BPF LSM.

Frankly, I couldn't care less whether IPE chooses to model the keyring
the same way. It just means it can't give equivalent security
guarantees. I'm confused why you have to speak for Fu and why you're so
defensive about this.

[1]: https://lore.kernel.org/all/CAHC9VhQ-cq-nD7uq3kv=SFSJyzO_CEgwzFeMcdbznTmPWJoy6g@mail.gmail.com