linux-kernel - Re: [PATCH] efi: pstore: Support late setup with TEE-backed efivars ops

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAC_iWjJ5DZLP_mzFOVTETPqVyG9C8NTXwLmx_b7JrcXAVaf2cQ@mail.gmail.com>
Date: Fri, 5 Dec 2025 12:56:12 +0200
From: Ilias Apalodimas <ilias.apalodimas@...aro.org>
To: Ard Biesheuvel <ardb@...nel.org>
Cc: Val Packett <val@...kett.cool>, Kees Cook <kees@...nel.org>, Tony Luck <tony.luck@...el.com>, 
	"Guilherme G. Piccoli" <gpiccoli@...lia.com>, linux-hardening@...r.kernel.org, 
	linux-efi@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] efi: pstore: Support late setup with TEE-backed efivars ops

On Fri, 5 Dec 2025 at 12:27, Ard Biesheuvel <ardb@...nel.org> wrote:
>
> On Thu, 4 Dec 2025 at 21:57, Val Packett <val@...kett.cool> wrote:
> >
> >
> > On 12/4/25 6:49 AM, Ilias Apalodimas wrote:
> > > Hi Val,
> > >
> > > On Wed, 3 Dec 2025 at 06:29, Val Packett <val@...kett.cool> wrote:
> > >> On some platforms, EFI variable services only become available when an
> > >> appropriate TEE driver is initialized such as qseecom, gsmi or stmm.
> > >>
> > >> This would work fine when efi_pstore was built as a module and loaded
> > >> late by userspace, but with CONFIG_EFI_VARS_PSTORE=y this driver would
> > >> quit due to non-writable efivars before the necessary driver had any
> > >> chance to load.
> > > The problem, at least for OP-TEE/StMM, is that writing the variables
> > > to an RPMB depends on a userspace application If CONFIG_RPMB is not
> > > selected. We have no guarantees that the app will still be alive.
> > > I don't know how gsmi or qseecom deal with writing variables. We can
> > > probably allow it for StMM if CONFIG_RPMB is enabled, but we'll have
> > > the right trigger to do so.
> >
> > qseecom/uefisecapp does not have any userspace requirements and works
> > fine with efi_pstore.
> >
> > I don't think complicating efi_pstore with extra logic about which ops
> > are fine would be worth it..
> >
> > Either way, it currently *already* tries to use whatever ops that have
> > been registered if it's loaded late as a module by systemd! The only
> > thing this patch changes is the CONFIG_EFI_VARS_PSTORE=y case.
> >
>
> OP-TEE/StMM's implementation of tee_set_variable_nonblocking() just
> returns EFI_UNSUPPORTED,

Yes that's a limitation imposed by Arm MM iirc.

> and so in practice, EFI pstore doesn't work at all there.

Exactly. It's been a while, but I vaguely remember that in v1 we had
pstore explicitly disabled from the Kconfig. But distros tend to use
it, so we ended up doing it like this, so they can enable the feature.

> I think this is fine, although it would be better to be
> upfront about this, and not expose the pstore FS at all in this case.
> And once we can provide an implementation (based on CONFIG_RPMB), it
> would be good to wire that up correctly as well.

I'll see if i can find hardware and time to test it. In theory we
should be find if the writes are wired up via the kernel and not
userspace.
If they are we can just define tee_set_variable_nonblocking() to a
working function if that Kconfig is selected.


Cheers
/Ilias
>
> > +static int efivars_pstore_init(void)
> > +{
> > +       if (pstore_disable)
> > +               return 0;
> > +
> > +       blocking_notifier_chain_register(&efivar_ops_nh,
> > +                                       &efivars_pstore_ops_notifier_block);
> > +
> > +       return efivars_pstore_setup();
> > +}
> > +
>
> Better to do the registration last, so there is no way
> efivars_pstore_setup() might ever race with itself.