Hi,
LOC monthly meeting is planned to take place Thursday January 28th(a)16.00
(UTC+1). This time we have two guest speakers, with two different topics.
- Clément Faure (NXP): HW crypto accelerator integration with crypto
framework in OP-TEE
- Sumit Garg (Linaro): TEE based Trusted Keys
This might take the whole meeting, but feel free to suggest topics you'd
like to
discuss otherwise (by replying to this email or write it directly in the
meeting
notes).
Meeting details:
---------------
Date/time: Thursday January 28th(a)16.00 (UTC+1)
https://everytimezone.com/s/c43ea835
Connection details: https://www.trustedfirmware.org/meetings/
Meeting notes: http://bit.ly/loc-notes
Project page: https://www.linaro.org/projects/#LOC
Regards,
Joakim on behalf of the Linaro OP-TEE team
Use flexible-array member introduced in C99 instead of zero-length
array. Most of zero-length array was already taken care in previous
patch [1]. Now modified few more cases which were not handled earlier.
[1]. https://patchwork.kernel.org/patch/11394197/
Signed-off-by: Tian Tao <tiantao6(a)hisilicon.com>
---
drivers/tee/optee/optee_msg.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tee/optee/optee_msg.h b/drivers/tee/optee/optee_msg.h
index 7b2d919..b1f1e90 100644
--- a/drivers/tee/optee/optee_msg.h
+++ b/drivers/tee/optee/optee_msg.h
@@ -199,7 +199,7 @@ struct optee_msg_arg {
u32 num_params;
/* num_params tells the actual number of element in params */
- struct optee_msg_param params[0];
+ struct optee_msg_param params[];
};
/**
--
2.7.4
On Fri, Jan 15, 2021 at 12:50:27PM +0000, Jens Wiklander via OP-TEE wrote:
> Hi Kris,
>
> On Thu, Jan 14, 2021 at 1:37 PM Kris Kwiatkowski <kris(a)amongbytes.com> wrote:
> >
> > Hi,
> >
> > I'm using HiKey 960 for my research project. I've noticed that
> > filesystem is not persistent between reboot. Is there a way
> > to change it, so that any change to file in the /etc will be
> > persistent?
>
> There's no easy way of doing that with our repo based builds I'm aware
> of. The purpose of our (OP-TEE team) builds is in principle to be able
> to execute xtest and other test programs. For this use case it's
> actually an advantage to start from a clean state each time. In your
> case I think you need to pick a suitable distribution and update it as
> needed to support OP-TEE. It could be worth looking at Yocto as there
> is some OP-TEE support already.
>
You can also give NFS a try, I tend to use that myself when playing with
OP-TEE and Raspberry Pi3. I.e., I basically just untar the rootfs
created by our setup into a folder that is exposed via NFS. Then in
addition to that I have a couple of helper scripts that copies the files
Jens mentioned below into that NFS folder when I need to update with
changed files (TA's, OP-TEE libs etc).
> Here's a short list of what's needed:
> 1. TF-A compiled with OP-TEE support (dispatcher in BL31 and load
> support in bl2)
> 2. OP-TEE included in the FIP loaded by TF-A
> 3. OP-TEE nodes in device tree
> 4. OP-TEE driver enabled in the kernel (recent upstream kernel should
> work in most cases)
> 5. tee-supplicant and libteec.so installed in the file system
> 6. tee-supplicant started
>
> With that in place you should be good to go.
>
> Cheers,
> Jens
--
Regards,
Joakim
Hi Kris,
On Thu, Jan 14, 2021 at 1:37 PM Kris Kwiatkowski <kris(a)amongbytes.com> wrote:
>
> Hi,
>
> I'm using HiKey 960 for my research project. I've noticed that
> filesystem is not persistent between reboot. Is there a way
> to change it, so that any change to file in the /etc will be
> persistent?
There's no easy way of doing that with our repo based builds I'm aware
of. The purpose of our (OP-TEE team) builds is in principle to be able
to execute xtest and other test programs. For this use case it's
actually an advantage to start from a clean state each time. In your
case I think you need to pick a suitable distribution and update it as
needed to support OP-TEE. It could be worth looking at Yocto as there
is some OP-TEE support already.
Here's a short list of what's needed:
1. TF-A compiled with OP-TEE support (dispatcher in BL31 and load
support in bl2)
2. OP-TEE included in the FIP loaded by TF-A
3. OP-TEE nodes in device tree
4. OP-TEE driver enabled in the kernel (recent upstream kernel should
work in most cases)
5. tee-supplicant and libteec.so installed in the file system
6. tee-supplicant started
With that in place you should be good to go.
Cheers,
Jens
[BCC all OP-TEE maintainers]
Hi OP-TEE maintainers & contributors,
OP-TEE v3.12.0 is scheduled to be released at 2021-01-15. So, now is
a good time to start testing the master branch on the various platforms
and report/fix any bugs.
The GitHub pull request for collecting Tested-by tags or any other
comments is https://github.com/OP-TEE/optee_os/pull/4291.
As usual, we will create a release candidate tag one week before the
release date for final testing.
In addition to that you can find some additional information related to
releases here: https://optee.readthedocs.io/en/latest/general/releases.html
Regards,
Joakim
Hi Robert,
Comments below.
On Mon, Dec 28, 2020 at 7:49 PM Robert Delien via OP-TEE
<op-tee(a)lists.trustedfirmware.org> wrote:
>
> Hi,
>
> As discussed earlier, our application requires secured display contents and
> is using a secure frame buffer.
>
> Now to transit from U-Boot to Op-tee as smoothly as possible, I would like
> to copy the contents from the U-Boot frame buffer into the Optee frame
> buffer upon LCD driver initialisation.
>
> The U-Boot frame buffer address is calculated at run time and I haven't
> found a hand-off mechanism, but the physical address can be easily read
> from the LCDIF peripheral's registers. Unfortunately, no MMU mapping is
> present per default for this physical address outside the TZDRAM area.
>
> Is it possible to temporarily map this rather arbitrary non-secure physical
> DDR address outside TZDRAM, so I can access it through a virtual address?
> Preferably in a way that I can also remove this mapping after copying the
> frame buffer?
Yes, it's actually easier than one might first imagine. I assume you
will interact with OP-TEE via a Pseudo TA. This framebuffer is normal
non-secure DDR from OP-TEE point of view, so it should be possible to
just supply it as a memref parameter when invoking the PTA.
Cheers,
Jens