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

[Luca Boccassi]

On Wed, 28 Oct 2026 at 12:42, James Bottomley
<James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote:
>
> On Tue, 2026-10-27 at 11:07 +0000, Luca Boccassi wrote:
> > On Mon, 26 Oct 2026 at 12:57, <luca.boccassi@xxxxxxxxx> wrote:
> > > 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.
>
> The attack sounds doable, but it also seems to be exploiting a gap in
> kexec policy: kexec is supposed to behave like a warm reboot so if boot
> policy requires UKI only then so should kexec and that sounds like the
> thing that should be fixed.

I don't think that's the case though, even before KHO/LUO existed,
kexec has never really behaved like a warm reboot, as for example boot
services do not run again, so various chains of trusts are not reset
(eg: a bootloader might now be blocked so warm reboot would not work,
but kexec would). And since KHO now exists, the difference is even
greater, as more and more state is retained across the boundary.

> What's the mechanism boot uses to ensure UKI only? So we can see if it
> can be adopted to kexec.

There isn't one, and I don't think there is correlation, as booting a
UKI is not the only way to boot a system. Eg: this problem applies
just as well to booting an arm system on uboot. So I really would not
tie this to UKI or UEFI specifics, it's more generic.

> > > 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
>
> I wouldn't do this because a) I don't think it's an IPE problem, I
> think it's a kexec one and b) distros get very tetchy about hard to
> solve feature anti dependencies.

Note that I wasn't suggesting an explicit conflict, but merely to
model the default values of the kconfigs with such a relationship,
allowing manually setting any combination the user wants. But it was
just an idea, maybe it's not worth it, dunno.

> > > 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.
>
> I'd document the need for trusted userspace on kexec if it was a boot
> requirement, yes.
>
> > 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?
>
> Well, yes, we do have a similar problem with the trusted keyrings.
> They're actually initialized from the shim created ..RT variables
> (which are volatile, but don't die on kexec).  On first boot they're
> initialized before user space, so we know they came from shim (or
> another trusted component in the boot chain) but if root uses UEFI RT
> services to add to a ..RT keyring, the added key will appear trusted
> after kexec.

If it is possible to overwrite the RT variables then yeah it sounds
like we want to preserve the machine/platform keyrings too via KHO.