Hi,
As part of opening up Linaro projects to the general public we plan to have
an open monthly meeting where we discuss Linaro's activities around OP-TEE.
The way that we've planned to do this is that we send out an email to this
email list (https://lists.trustedfirmware.org/mailman/listinfo/op-tee) to
gather topics to discuss. If there are no topics, then there is no meeting.
Anyone can suggest a topic by replying to this email thread.
As a first topic for this first meeting, we want to talk a bit about:
- Linaro and the relation to TrustedFirmware.org when it comes to OP-TEE.
- Where to find information.
- What is on the agenda for the next development cycle.
Calendar invitation? I could just send one out here and now, but due to
Zoom bombing and that it'd be a logistic exercise inviting people, I've
decided to try another approach and that is to provide the connection
details in the meeting notes and leave it up to the attendees to add it to
their own calendars. To try to limit confusion I've explicitly added the
timezone and a link to everytimezone.com so it should be easy to get the
information in your own timezone. If this approach doesn't turn out to be
good, then we will try something different in the future (I understand that
canceling or shifting day/time will become a problem).
Meeting details:
---------------
Date/time: Thursday Aug 27th(a)16.00 (UTC+2)
https://everytimezone.com/s/12a83ab5
Invitation/connection details: In the meeting notes
Meeting notes:
https://docs.google.com/document/d/15XsqgGktCrRRWiqyaz-erp_cZykwGjkBkhMD2Xt…
Regards,
Joakim on behalf of the Linaro OP-TEE team
[BCC all OP-TEE maintainers]
Hi OP-TEE maintainers & contributors,
It is time again to prepare for a new OP-TEE release (3.10.0). Target is
Friday, August 21st which leaves us 3 weeks to finalize the release.
Please start testing your favorite platform(s) and report any issue in
this pull request [1]. I will create a release candidate tag one week
before the release date, at which point we will do some more testing and
I will collect Tested-by tags in the same pull request.
[1] https://github.com/OP-TEE/optee_os/pull/4008
Thanks!
Regards,
--
Jerome
The current code waits for data to be available before attempting a
second read. However the second read would not be executed as the
while loop will exit.
This fix does not wait if all data has been read (skips the call to
msleep(0)) and reads a second time if partial data was retrieved on
the first read.
Worth noticing that since msleep(0) schedules a one jiffy timeout is
better to skip such a call.
Signed-off-by: Jorge Ramirez-Ortiz <jorge(a)foundries.io>
Reviewed-by: Sumit Garg <sumit.garg(a)linaro.org>
---
drivers/char/hw_random/optee-rng.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/char/hw_random/optee-rng.c b/drivers/char/hw_random/optee-rng.c
index 5bc4700c4dae..a99d82949981 100644
--- a/drivers/char/hw_random/optee-rng.c
+++ b/drivers/char/hw_random/optee-rng.c
@@ -122,14 +122,14 @@ static int optee_rng_read(struct hwrng *rng, void *buf, size_t max, bool wait)
if (max > MAX_ENTROPY_REQ_SZ)
max = MAX_ENTROPY_REQ_SZ;
- while (read == 0) {
+ while (read < max) {
rng_size = get_optee_rng_data(pvt_data, data, (max - read));
data += rng_size;
read += rng_size;
if (wait && pvt_data->data_rate) {
- if (timeout-- == 0)
+ if ((timeout-- == 0) || (read == max))
return read;
msleep((1000 * (max - read)) / pvt_data->data_rate);
} else {
--
2.17.1
Data rates of MAX_UINT32 will schedule an unnecessary one jiffy
timeout on the call to msleep. Avoid this scenario by using 0 as the
unlimited data rate.
Signed-off-by: Jorge Ramirez-Ortiz <jorge(a)foundries.io>
---
drivers/char/hw_random/optee-rng.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/char/hw_random/optee-rng.c b/drivers/char/hw_random/optee-rng.c
index 49b2e02537dd..5bc4700c4dae 100644
--- a/drivers/char/hw_random/optee-rng.c
+++ b/drivers/char/hw_random/optee-rng.c
@@ -128,7 +128,7 @@ static int optee_rng_read(struct hwrng *rng, void *buf, size_t max, bool wait)
data += rng_size;
read += rng_size;
- if (wait) {
+ if (wait && pvt_data->data_rate) {
if (timeout-- == 0)
return read;
msleep((1000 * (max - read)) / pvt_data->data_rate);
--
2.17.1
Hi,
In parallel with - and based on - the work by Jens to enable PSA FF-A as a transport for the SMC ABI (recently merged to the upstream as PR #3908) there's an effort to provide a fully-functional SPMC component in OP-TEE to manage S-EL0 Secure Partitions, with the goal of providing a similar set of PSA Root of Trust services over OP-TEE as presently supported for M-profile processors, while also providing a standard execution framework and ABI for potential integration of 3rd party partitions, such as StMM.
Please note that this work is currently at the prototyping stage and is managed as a fork on trustedfirmware.org, but is planned to be merged with the official OP-TEE stream as it matures.
There's an initial set of patches on review to provide
* A library for S-EL0 SPs to access FF-A ABI at the SVC call interface:
https://review.trustedfirmware.org/c/OP-TEE/optee_os/+/4751
* A change to introduce an SP build system to OP-TEE:
https://review.trustedfirmware.org/c/OP-TEE/optee_os/+/4752
* OP-TEE kernel changes to support initialization and context management of SPs and the forwarding of FF-A messages to their designated endpoints:
https://review.trustedfirmware.org/c/OP-TEE/optee_os/+/4987
All related open reviews at the moment can be found here:
https://review.trustedfirmware.org/q/project:OP-TEE%252Foptee_os+status:open
For the S-EL1 SPMC configuration functionality and requirements see the PSA FF-A specification (https://developer.arm.com/documentation/den0077/latest)
Work is in progress to showcase the capabilities of the framework using a subset of PSA Crypto API and also to propose a standardized protocol layer for partitions, but as mentioned work is still at the early stages so expect gradual increments in functionality and flexibility.
Any questions and feedback are very welcome
Cheers,
Miklos
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Hi Jerome,
On Fri, Jul 24, 2020 at 02:57:34PM +0000, Jérôme Forissier via OP-TEE wrote:
> Hi,
>
> Anyone know if the planned dates of OP-TEE releases are publicly available
> somewhere?
>
Still a bit legacy regarding that, i.e., still tracked in the Linaro
Jira instance. Even though the "Linaro OP-TEE Contributions" is publicly
available, the release schedule seems to be locked down.
> Readthedocs [1] documents that we do quarterly releases, but it would help
> to have a more precise indication, at least for the next (upcoming) release.
>
Agree, I can replicate what we have in the Jira instance and put that on
the release page you're referring to.
> Can we count on 3.10.0 being made available by the end of August?
>
Yes, so it's about time to initiate the release work for that tag. As
maintainers, let's sync up on that separately.
Here are the dates for future releases.
Version Start date Release date
OP-TEE 3.10.0 23/May/20 21/Aug/20
OP-TEE 3.11.0 22/Aug/20 16/Oct/20
OP-TEE 3.12.0 17/Oct/20 15/Jan/21
OP-TEE 3.13.0 16/Jan/21 16/Apr/21
> [1] https://optee.readthedocs.io/en/latest/general/releases.html
>
> Thanks,
> --
> Jerome
> --
> OP-TEE mailing list
> OP-TEE(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/op-tee
--
Regards,
Joakim
Hi,
Anyone know if the planned dates of OP-TEE releases are publicly available
somewhere?
Readthedocs [1] documents that we do quarterly releases, but it would help
to have a more precise indication, at least for the next (upcoming) release.
Can we count on 3.10.0 being made available by the end of August?
[1] https://optee.readthedocs.io/en/latest/general/releases.html
Thanks,
--
Jerome
On Sat, 18 Jul 2020 13:50:58 -0300
"Daniel W. S. Almeida" <dwlsalmeida(a)gmail.com> wrote:
> TEE bus infrastructure registers following APIs:
> -- match(): iterates over the client driver UUID table to find a corresponding
> - match for device UUID. If a match is found, then this particular device is
> - probed via corresponding probe API registered by the client driver. This
> - process happens whenever a device or a client driver is registered with TEE
> - bus.
> -- uevent(): notifies user-space (udev) whenever a new device is registered on
> - TEE bus for auto-loading of modularized client drivers.
> +
> +match():
> + iterates over the client driver UUID table to find a corresponding
> + match for device UUID. If a match is found, then this particular device is
> + probed via corresponding probe API registered by the client driver. This
> + process happens whenever a device or a client driver is registered with TEE
> + bus.
> +
> +uevent():
> + notifies user-space (udev) whenever a new device is registered on
> + TEE bus for auto-loading of modularized client drivers.
Just FWIW, this could have been fixed by adding a blank line between the
two bulleted entries. This fix is fine too, though, applied, thanks.
jon
Data rates of MAX_UINT32 will schedule an unnecessary one jiffy
timeout on the call to msleep. Avoid this scenario by using 0 as the
unlimited data rate.
Signed-off-by: Jorge Ramirez-Ortiz <jorge(a)foundries.io>
---
drivers/char/hw_random/optee-rng.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/char/hw_random/optee-rng.c b/drivers/char/hw_random/optee-rng.c
index 49b2e02537dd..5bc4700c4dae 100644
--- a/drivers/char/hw_random/optee-rng.c
+++ b/drivers/char/hw_random/optee-rng.c
@@ -128,7 +128,7 @@ static int optee_rng_read(struct hwrng *rng, void *buf, size_t max, bool wait)
data += rng_size;
read += rng_size;
- if (wait) {
+ if (wait && pvt_data->data_rate) {
if (timeout-- == 0)
return read;
msleep((1000 * (max - read)) / pvt_data->data_rate);
--
2.17.1
Hello arm-soc maintainers,
Please pull these patches enabling multi-stage OP-TEE bus enumeration
and also adds a TPM driver for a OP-TEE based fTPM Trusted Application.
The TPM driver depends on and takes advantage of the multi-stage OP-TEE bus
enumeration by indicating that it should be probed after tee-supplicant has
been started.
Jarkko, one of the TPM maintainers, has been involved in reviewing these
patches and agrees that I can include the TPM patch in the pull request.
Thanks,
Jens
The following changes since commit 3d77e6a8804abcc0504c904bd6e5cdf3a5cf8162:
Linux 5.7 (2020-05-31 16:49:15 -0700)
are available in the Git repository at:
git://git.linaro.org/people/jens.wiklander/linux-tee.git tags/optee-bus-for-v5.9
for you to fetch changes up to 9f1944c23c8cb1c033b73de80cf6c612a2a80a2b:
tpm_ftpm_tee: register driver on TEE bus (2020-07-10 09:41:58 +0200)
----------------------------------------------------------------
Enable multi-stage OP-TEE bus enumeration
Probes drivers on the OP-TEE bus in two steps. First for drivers which
do not depend on tee-supplicant. After tee-supplicant has been started
probe the devices which do depend on tee-supplicant.
Also introduces driver which uses an OP-TEE based fTPM Trusted
Application depends on tee-supplicant NV RAM implementation based on
RPMB secure storage.
----------------------------------------------------------------
Maxim Uvarov (3):
optee: use uuid for sysfs driver entry
optee: enable support for multi-stage bus enumeration
tpm_ftpm_tee: register driver on TEE bus
Documentation/ABI/testing/sysfs-bus-optee-devices | 8 +++
MAINTAINERS | 1 +
drivers/char/tpm/tpm_ftpm_tee.c | 70 +++++++++++++++++++----
drivers/tee/optee/core.c | 27 ++++++++-
drivers/tee/optee/device.c | 38 ++++++------
drivers/tee/optee/optee_private.h | 10 +++-
6 files changed, 119 insertions(+), 35 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-bus-optee-devices