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

[Luca Boccassi]

On Mon, 26 Oct 2026 at 12:57, <luca.boccassi at gmail.com> wrote:
>
> On Thu, 2026-10-22 at 13:18 -0400, Paul Moore wrote:
> > On Thu, Oct 22, 2026 at 6:19 AM Christian Brauner
> > <brauner at kernel.org> wrote:
> > > On Wed, Oct 21, 2026 at 12:51:35PM -0400, Paul Moore wrote:
> > >
> >
> > ...
> >
> > >
> > > > 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?
> >
> > As I said before, (emphasis now added for claification) "... *if* it
> > causes IPE or existing IPE uses a lot of pain ...".  I intentionally
> > did not make a claim either way.  Once again, I wanted to provide Fan
> > some support in case there was an issue and he found himself in a
> > position where he had to push back to preserve IPE's model.
>
> I think there is one issue with the design pattern where keyrings are
> set up in userspace, that I have mentioned a few times already and I
> got documented in
> https://www.freedesktop.org/software/systemd/man/latest/systemd-system.conf.html#RestrictFileSystemAccess=
> as well: they are trivially bypassable if the kernel has kexec enabled
> and it is signed. The security model relies on the "good" userspace
> running first, but if kexec is enabled, there's no guarantee that will
> be the case, and as far as I can tell it gives root trivial capability
> of overriding it and extending the trust chain as the attacker wishes.
>
> IPE specifically was designed to avoid exactly that, and ensure
> userspace could not execute untrusted code, even with root privileges.
> With this enabled by default, userspace can just load the same signed
> kernel image, passing in compromised initrd and command line, and gain
> arbitrary code execution on the host, since only the kernel binary
> itself is verified, and anything goes for the rest of the kexec
> parameters.
>
> This is of course not to say this new IPE keyring shouldn't be added.
> But perhaps it would be nicer if the default build flag was mutually
> exclusive with kexec being enabled? Not sure if that can be expressed
> in Kconfig though? default: yes-if-kexec-off, no-if-kexec-on
>
> At the very least IMHO this relationship should be documented
> explicitly in the kconfig blurb, as it seems to me it's a major footgun
> to leave laying around, and users might not necessarily be aware of it.

KHO/keyring folks, what would you think about preserving sealed
keyrings across kexec via KHO so that the chain of trust can't be
reset by userspace? Good idea/bad idea/yes send patches/no go
away/etc?