From: Ilias Apalodimas <ilias.apalodimas@linaro.org>
To: Jan Kiszka <jan.kiszka@siemens.com>
Cc: Masahisa Kojima <masahisa.kojima@linaro.org>,
Ard Biesheuvel <ardb@kernel.org>,
Jens Wiklander <jens.wiklander@linaro.org>,
Sumit Garg <sumit.garg@linaro.org>,
linux-kernel@vger.kernel.org, op-tee@lists.trustedfirmware.org,
Johan Hovold <johan+linaro@kernel.org>,
Jeremy Kerr <jk@ozlabs.org>,
linux-efi@vger.kernel.org
Subject: Re: [PATCH v6 4/4] efivarfs: automatically update super block flag
Date: Thu, 22 Jun 2023 21:56:46 +0300 [thread overview]
Message-ID: <ZJSZbmUz583pszny@hera> (raw)
In-Reply-To: <5fe03be6-8c95-0bfa-687d-68e7ddffd97c@siemens.com>
Hi Kojima-san, Jan
On Thu, Jun 22, 2023 at 04:58:50PM +0200, Jan Kiszka wrote:
> On 22.06.23 10:51, Masahisa Kojima wrote:
> > efivar operation is updated when the tee_stmm_efi module is probed.
> > tee_stmm_efi module supports SetVariable runtime service,
> > but user needs to manually remount the efivarfs as RW to enable
> > the write access if the previous efivar operation does not support
> > SerVariable and efivarfs is mounted as read-only.
> >
> > This commit notifies the update of efivar operation to
> > efivarfs subsystem, then drops SB_RDONLY flag if the efivar
> > operation supports SetVariable.
>
> But it does not re-add it and prevents further requests to the TA (that
> will only cause panics there) when the daemon terminates, does it?
It doesn't, but I think I got a better way out. Even what you suggest won't
solve the problem entirely. For the sake of context
- The kernel decides between the RO/RW depending on the SetVariable ptr
- The stmm *module* registers and swaps the RT calls -- and the ptr is now
valid. Note here that the module probe function will run only if the
supplicant is running
- Once the module is inserted the filesystem will be remounted even without
the supplicant running, which would not trigger an oops, but an hard to
decipher error message from OP-TEE.
So even if we switch the permissions back to RO when the supplicant dies,
someone can still remount it as RW and trigger the same error.
Which got me thinking and staring the TEE subsystem a bit more. The
supplicant is backed by a /dev file, which naturally has .open() and
.release() callbacks. Why don't we leave the module perform the initial
setup -- e.g talk to StMM and make sure it's there, setup the necessary
buffers etc and defer the actual swapping of the efivar ops and the
filesystem permissions there? I might 'feel' a bit weird, but as I
mentioned the module probe function only runs if the supplicant is running
anyway
Cheers
/Ilias
>
> Jan
>
> --
> Siemens AG, Technology
> Competence Center Embedded Linux
>
next prev parent reply other threads:[~2023-06-22 18:56 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20230622085112.1521-1-masahisa.kojima@linaro.org>
2023-06-22 8:51 ` [PATCH v6 1/4] efi: expose efivar generic ops register function Masahisa Kojima
2023-06-22 8:51 ` [PATCH v6 2/4] efi: Add EFI_ACCESS_DENIED status code Masahisa Kojima
2023-06-22 8:51 ` [PATCH v6 3/4] efi: Add tee-based EFI variable driver Masahisa Kojima
2023-06-22 8:51 ` [PATCH v6 4/4] efivarfs: automatically update super block flag Masahisa Kojima
2023-06-22 14:58 ` Jan Kiszka
2023-06-22 18:56 ` Ilias Apalodimas [this message]
2023-07-24 2:52 ` Masahisa Kojima
2023-07-24 10:21 ` Ilias Apalodimas
2023-07-26 4:49 ` Masahisa Kojima
2023-07-27 2:55 ` Masahisa Kojima
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZJSZbmUz583pszny@hera \
--to=ilias.apalodimas@linaro.org \
--cc=ardb@kernel.org \
--cc=jan.kiszka@siemens.com \
--cc=jens.wiklander@linaro.org \
--cc=jk@ozlabs.org \
--cc=johan+linaro@kernel.org \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=masahisa.kojima@linaro.org \
--cc=op-tee@lists.trustedfirmware.org \
--cc=sumit.garg@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).