From: Jan Kiszka <jan.kiszka@siemens.com>
To: Ilias Apalodimas <ilias.apalodimas@linaro.org>
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>
Subject: Re: [PATCH v6 0/4] introduce tee-based EFI Runtime Variable Service
Date: Thu, 22 Jun 2023 20:32:44 +0200 [thread overview]
Message-ID: <65d010fa-c801-eb4f-352f-8bfb52a67c85@siemens.com> (raw)
In-Reply-To: <CAC_iWjJ28uKVpz_FrJ6dcUjCkrV9w5UO4WRr9SQxYFPmtmj59w@mail.gmail.com>
On 22.06.23 17:04, Ilias Apalodimas wrote:
> Hi Jan,
>
> On Thu, 22 Jun 2023 at 17:56, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>
>> On 22.06.23 10:51, Masahisa Kojima wrote:
>>> This series introduces the tee based EFI Runtime Variable Service.
>>>
>>> The eMMC device is typically owned by the non-secure world(linux in
>>> this case). There is an existing solution utilizing eMMC RPMB partition
>>> for EFI Variables, it is implemented by interacting with
>>> OP-TEE, StandaloneMM(as EFI Variable Service Pseudo TA), eMMC driver
>>> and tee-supplicant. The last piece is the tee-based variable access
>>> driver to interact with OP-TEE and StandaloneMM.
>>>
>>> Changelog:
>>> v5 -> v6
>>> - new patch #4 is added in this series, #1-#3 patches are unchanged.
>>> automatically update super block flag when the efivarops support
>>> SetVariable runtime service, so that user does not need to manually
>>> remount the efivarfs as RW.
>>
>> But that is not yet resolving the architectural problem with that
>> userspace daemon dependency. What are the next steps for that now?
>
> We are trying to find some cycles to work on that, however, I don't
> have a time estimate on that. But the question is different here.
> Since this addresses the problems distros have wrt to SetVariableRT
> (even for a limited set of platforms) are we ok pulling this in? I
> can't think of a technical reason we shouldn't. The supplicant
> limitations are known and the firrmwareTPM has a similar set of
> problems.
It will not change we have to do on the distro side because we have to
deal not only with the startup issue and StMM but also with fTPM and
with shutdown. Only an in-kernel supplicant for RPMB would resolve that
according to my understanding.
But the question is fair if we can evolve from this stage here to an
in-kernel approach without causing breakages or other headache to
distros adopting it (too early). That's why I asked for the roadmap.
Jan
--
Siemens AG, Technology
Competence Center Embedded Linux
next prev parent reply other threads:[~2023-06-22 18:33 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-22 8:51 Masahisa Kojima
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
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
2023-06-22 14:56 ` [PATCH v6 0/4] introduce tee-based EFI Runtime Variable Service Jan Kiszka
2023-06-22 15:04 ` Ilias Apalodimas
2023-06-22 18:32 ` Jan Kiszka [this message]
2023-06-22 19:03 ` Ilias Apalodimas
2023-06-22 20:44 ` Jan Kiszka
2023-06-23 9:31 ` Ilias Apalodimas
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=65d010fa-c801-eb4f-352f-8bfb52a67c85@siemens.com \
--to=jan.kiszka@siemens.com \
--cc=ardb@kernel.org \
--cc=ilias.apalodimas@linaro.org \
--cc=jens.wiklander@linaro.org \
--cc=johan+linaro@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
all inboxes | Powered by JetHome®