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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMj1kXHCkrnKkFDbvJPS_ykdG_xic=OcvS7hXXwY6XT8oiqkEA@mail.gmail.com>
Date: Fri, 5 Dec 2025 11:27:17 +0100
From: Ard Biesheuvel <ardb@...nel.org>
To: Val Packett <val@...kett.cool>
Cc: Ilias Apalodimas <ilias.apalodimas@...aro.org>, 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 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, and so in practice, EFI pstore doesn't work
at all there. 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.

> +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.