From: Allen Pais <apais(a)linux.microsoft.com>
The following out of memory errors are seen on kexec reboot
from the optee core.
[ 0.368428] tee_bnxt_fw optee-clnt0: tee_shm_alloc failed
[ 0.368461] tee_bnxt_fw: probe of optee-clnt0 failed with error -22
tee_shm_release() is not invoked on dma shm buffer.
Implement .shutdown() in optee core as well as bnxt firmware driver
to handle the release of the buffers correctly.
More info:
https://github.com/OP-TEE/optee_os/issues/3637
v2:
keep the .shutdown() method simple. [Jens Wiklander]
Allen Pais (2):
optee: fix tee out of memory failure seen during kexec reboot
firmware: tee_bnxt: implement shutdown method to handle kexec reboots
drivers/firmware/broadcom/tee_bnxt_fw.c | 9 +++++++++
drivers/tee/optee/core.c | 20 ++++++++++++++++++++
2 files changed, 29 insertions(+)
--
2.25.1
Hi,
On Thu, Feb 25, 2021 at 9:41 AM Joakim Bech via OP-TEE <
op-tee(a)lists.trustedfirmware.org> wrote:
> Hi Jorge,
>
> On Wed, 24 Feb 2021 at 18:14, Jorge Ramirez <jorge(a)foundries.io> wrote:
>
> > Sorry Joakim.
> > I guess it is too late now but It would have been good to talk about the
> > TEE strategy/direction with RNG.
> > 1) how often do we seed the PRNG.
> > 2) should we always use PRNG and only use HWRNG to seed if with a certain
> > cadence.
> > 3) how do we measure the quality of an RNG in OPTEE (how do we guarantee
> > no regressions)
> > this would be really an open discussion more than anything else (unless
> > there is a matematician amongst us)
> >
> Yes, good suggestions. I'll add it to the next meeting (March 25:th).
>
And now that I think of it... there is this big OCALL contribution that has
been mostly stalled for months...
https://github.com/OP-TEE/optee_os/pull/3673
We should discuss what to do with it.
Regards,
--
Jerome
Sorry Joakim.
I guess it is too late now but It would have been good to talk about the
TEE strategy/direction with RNG.
1) how often do we seed the PRNG.
2) should we always use PRNG and only use HWRNG to seed if with a certain
cadence.
3) how do we measure the quality of an RNG in OPTEE (how do we guarantee no
regressions)
this would be really an open discussion more than anything else (unless
there is a matematician amongst us)
On Wed, Feb 24, 2021 at 9:18 AM Joakim Bech via OP-TEE <
op-tee(a)lists.trustedfirmware.org> wrote:
> Hi,
>
> Haven't received any suggestions for topics to discuss, so no agenda. No
> agenda means no meeting and therefore I'm cancelling the LOC meeting that
> was scheduled for tomorrow.
>
> Regards,
> Joakim
>
>
> On Wed, 17 Feb 2021 at 15:47, Joakim Bech <joakim.bech(a)linaro.org> wrote:
>
> > Hi,
> >
> > LOC monthly meeting is planned to take place on Thursday February 25th @
> > 16.00 (UTC+1).
> >
> > We're looking for topics to discuss in general. Eventually we'll have a
> > presentation from Achin Gupta from Arm talking about the FF-A spec.
> >
> > Meeting details:
> > ---------------
> > Date/time: Thursday Feb 25th(a)16.00 (UTC+1)
> > https://everytimezone.com/s/c4e5d6a3
> > 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
> >
>
On 1/21/21 1:02 AM, Jarkko Sakkinen via OP-TEE wrote:
> On Wed, Jan 20, 2021 at 12:53:28PM +0530, Sumit Garg wrote:
>> On Wed, 20 Jan 2021 at 07:01, Jarkko Sakkinen <jarkko(a)kernel.org> wrote:
>>>
>>> On Tue, Jan 19, 2021 at 12:30:42PM +0200, Jarkko Sakkinen wrote:
>>>> On Fri, Jan 15, 2021 at 11:32:31AM +0530, Sumit Garg wrote:
>>>>> On Thu, 14 Jan 2021 at 07:35, Jarkko Sakkinen <jarkko(a)kernel.org> wrote:
>>>>>>
>>>>>> On Wed, Jan 13, 2021 at 04:47:00PM +0530, Sumit Garg wrote:
>>>>>>> Hi Jarkko,
>>>>>>>
>>>>>>> On Mon, 11 Jan 2021 at 22:05, Jarkko Sakkinen <jarkko(a)kernel.org> wrote:
>>>>>>>>
>>>>>>>> On Tue, Nov 03, 2020 at 09:31:44PM +0530, Sumit Garg wrote:
>>>>>>>>> Add support for TEE based trusted keys where TEE provides the functionality
>>>>>>>>> to seal and unseal trusted keys using hardware unique key.
>>>>>>>>>
>>>>>>>>> Refer to Documentation/tee.txt for detailed information about TEE.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Sumit Garg <sumit.garg(a)linaro.org>
>>>>>>>>
>>>>>>>> I haven't yet got QEMU environment working with aarch64, this produces
>>>>>>>> just a blank screen:
>>>>>>>>
>>>>>>>> ./output/host/usr/bin/qemu-system-aarch64 -M virt -cpu cortex-a53 -smp 1 -kernel output/images/Image -initrd output/images/rootfs.cpio -serial stdio
>>>>>>>>
>>>>>>>> My BuildRoot fork for TPM and keyring testing is located over here:
>>>>>>>>
>>>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/buildroot-tpmdd.git/
>>>>>>>>
>>>>>>>> The "ARM version" is at this point in aarch64 branch. Over time I will
>>>>>>>> define tpmdd-x86_64 and tpmdd-aarch64 boards and everything will be then
>>>>>>>> in the master branch.
>>>>>>>>
>>>>>>>> To create identical images you just need to
>>>>>>>>
>>>>>>>> $ make tpmdd_defconfig && make
>>>>>>>>
>>>>>>>> Can you check if you see anything obviously wrong? I'm eager to test this
>>>>>>>> patch set, and in bigger picture I really need to have ready to run
>>>>>>>> aarch64 environment available.
>>>>>>>
>>>>>>> I would rather suggest you to follow steps listed here [1] as to test
>>>>>>> this feature on Qemu aarch64 we need to build firmwares such as TF-A,
>>>>>>> OP-TEE, UEFI etc. which are all integrated into OP-TEE Qemu build
>>>>>>> system [2]. And then it would be easier to migrate them to your
>>>>>>> buildroot environment as well.
>>>>>>>
>>>>>>> [1] https://lists.trustedfirmware.org/pipermail/op-tee/2020-May/000027.html
>>>>>>> [2] https://optee.readthedocs.io/en/latest/building/devices/qemu.html#qemu-v8
>>>>>>>
>>>>>>> -Sumit
>>>>>>
>>>>>> Can you provide 'keyctl_change'? Otherwise, the steps are easy to follow.
>>>>>>
>>>>>
>>>>> $ cat keyctl_change
>>>>> diff --git a/common.mk b/common.mk
>>>>> index aeb7b41..663e528 100644
>>>>> --- a/common.mk
>>>>> +++ b/common.mk
>>>>> @@ -229,6 +229,7 @@ BR2_PACKAGE_OPTEE_TEST_SDK ?= $(OPTEE_OS_TA_DEV_KIT_DIR)
>>>>> BR2_PACKAGE_OPTEE_TEST_SITE ?= $(OPTEE_TEST_PATH)
>>>>> BR2_PACKAGE_STRACE ?= y
>>>>> BR2_TARGET_GENERIC_GETTY_PORT ?= $(if
>>>>> $(CFG_NW_CONSOLE_UART),ttyAMA$(CFG_NW_CONSOLE_UART),ttyAMA0)
>>>>> +BR2_PACKAGE_KEYUTILS := y
>>>>>
>>>>> # All BR2_* variables from the makefile or the environment are appended to
>>>>> # ../out-br/extra.conf. All values are quoted "..." except y and n.
>>>>> diff --git a/kconfigs/qemu.conf b/kconfigs/qemu.conf
>>>>> index 368c18a..832ab74 100644
>>>>> --- a/kconfigs/qemu.conf
>>>>> +++ b/kconfigs/qemu.conf
>>>>> @@ -20,3 +20,5 @@ CONFIG_9P_FS=y
>>>>> CONFIG_9P_FS_POSIX_ACL=y
>>>>> CONFIG_HW_RANDOM=y
>>>>> CONFIG_HW_RANDOM_VIRTIO=y
>>>>> +CONFIG_TRUSTED_KEYS=y
>>>>> +CONFIG_ENCRYPTED_KEYS=y
>>>>>
>>>>>> After I've successfully tested 2/4, I'd suggest that you roll out one more
>>>>>> version and CC the documentation patch to Elaine and Mini, and clearly
>>>>>> remark in the commit message that TEE is a standard, with a link to the
>>>>>> specification.
>>>>>>
>>>>>
>>>>> Sure, I will roll out the next version after your testing.
>>>>
>>>> Thanks, I'll try this at instant, and give my feedback.
>>>
>>> I bump into this:
>>>
>>> $ make run-only
>>> ln -sf /home/jarkko/devel/tpm/optee/build/../out-br/images/rootfs.cpio.gz /home/jarkko/devel/tpm/optee/build/../out/bin/
>>> ln: failed to create symbolic link '/home/jarkko/devel/tpm/optee/build/../out/bin/': No such file or directory
>>> make: *** [Makefile:194: run-only] Error 1
>>>
>>
>> Could you check if the following directory tree is built after
>> executing the below command?
>>
>> $ make -j`nproc`
>> CFG_IN_TREE_EARLY_TAS=trusted_keys/f04a0fe7-1f5d-4b9b-abf7-619b85b4ce8c
>>
>> $ tree out/bin/
>> out/bin/
>> ├── bl1.bin -> /home/sumit/build/optee/build/../trusted-firmware-a/build/qemu/release/bl1.bin
>> ├── bl2.bin -> /home/sumit/build/optee/build/../trusted-firmware-a/build/qemu/release/bl2.bin
>> ├── bl31.bin ->
>> /home/sumit/build/optee/build/../trusted-firmware-a/build/qemu/release/bl31.bin
>> ├── bl32.bin ->
>> /home/sumit/build/optee/build/../optee_os/out/arm/core/tee-header_v2.bin
>> ├── bl32_extra1.bin ->
>> /home/sumit/build/optee/build/../optee_os/out/arm/core/tee-pager_v2.bin
>> ├── bl32_extra2.bin ->
>> /home/sumit/build/optee/build/../optee_os/out/arm/core/tee-pageable_v2.bin
>> ├── bl33.bin ->
>> /home/sumit/build/optee/build/../edk2/Build/ArmVirtQemuKernel-AARCH64/RELEASE_GCC49/FV/QEMU_EFI.fd
>> ├── Image -> /home/sumit/build/optee/build/../linux/arch/arm64/boot/Image
>> └── rootfs.cpio.gz ->
>> /home/sumit/build/optee/build/../out-br/images/rootfs.cpio.gz
>>
>> 0 directories, 9 files
>>
>> -Sumit
>
> I actually spotted a build error that was unnoticed last time:
>
> make[2]: Entering directory '/home/jarkko/devel/tpm/optee/edk2/BaseTools/Tests'
> /bin/sh: 1: python: not found
>
> I'd prefer not to install Python2. It has been EOL over a year.
AFAIK, everything should build fine with Python3. On my Ubuntu 20.04
machine, this is accomplished by installing package "python-is-python3"
(after uninstalling "python-is-python2" if need be).
$ ls -l /usr/bin/python
lrwxrwxrwx 1 root root 7 Apr 15 2020 /usr/bin/python -> python3
--
Jerome
From: Allen Pais <apais(a)linux.microsoft.com>
The following out of memory errors are seen on kexec reboot
from the optee core.
[ 0.368428] tee_bnxt_fw optee-clnt0: tee_shm_alloc failed
[ 0.368461] tee_bnxt_fw: probe of optee-clnt0 failed with error -22
tee_shm_release() is not invoked on dma shm buffer.
Implement .shutdown() in optee core as well as bnxt firmware driver
to handle the release of the buffers correctly.
More info:
https://github.com/OP-TEE/optee_os/issues/3637
Allen Pais (2):
optee: fix tee out of memory failure seen during kexec reboot
firmware: tee_bnxt: implement shutdown method to handle kexec reboots
drivers/firmware/broadcom/tee_bnxt_fw.c | 9 ++++
drivers/tee/optee/core.c | 69 ++++++++++++++++++-------
2 files changed, 58 insertions(+), 20 deletions(-)
--
2.25.1
Hi,
LOC monthly meeting is planned to take place on Thursday February 25th @
16.00 (UTC+1).
We're looking for topics to discuss in general. Eventually we'll have a
presentation from Achin Gupta from Arm talking about the FF-A spec.
Meeting details:
---------------
Date/time: Thursday Feb 25th(a)16.00 (UTC+1)
https://everytimezone.com/s/c4e5d6a3
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
Hi Robert,
On 2/22/21 11:01 AM, Robert Delien via OP-TEE wrote:
> Hi,
>
> In imx_csu.c, the Central Security Unit's CSU_CSL*n* registers are set,
> configuring access privileges for different peripherals. These registers
> range from CSU_CSL0 (@ 0x021c0000) to CSU_CSL39 (@ 0x021c009c).
>
> The different i.MX6 platform variants each have their individual tables,
> filled with sets of CSL index and register value, terminated by a sentinel
> set with the index set to -1. (the reason for the parentheses around -1
> espaces me)
>
> in .../core/arch/arm/plat-imx/drivers/imx_csu.c:csu_init()@115, a while
> loop runs through this aforementioned table, setting the CSL registers
> according to the table. However, this loop loops on CSL index values > 0:
> while (csu_setting->csu_index *>* 0) {
> io_write32(csu_base + (csu_setting->csu_index * 4),
> csu_setting->value);
>
> csu_setting++;
> }
> I think it should loop on CSL index values >= 0, because index 0 is a valid
> index, utilized for the PWM peripherals. (I also think csl_index is a more
> descriptive name, but that's besides the point).
>
> I have attached a patch for his.
It does look like a genuine bug to me, but I will let the i.MX expert
comment further. Unfortunately, the OP-TEE ML strips attachments. Would
you mind creating a GitHub pull request [1] (preferred method), or send
the patch inline?
[1] https://github.com/OP-TEE/optee_os/pulls
Thanks,
--
Jerome
Hi,
In imx_csu.c, the Central Security Unit's CSU_CSL*n* registers are set,
configuring access privileges for different peripherals. These registers
range from CSU_CSL0 (@ 0x021c0000) to CSU_CSL39 (@ 0x021c009c).
The different i.MX6 platform variants each have their individual tables,
filled with sets of CSL index and register value, terminated by a sentinel
set with the index set to -1. (the reason for the parentheses around -1
espaces me)
in .../core/arch/arm/plat-imx/drivers/imx_csu.c:csu_init()@115, a while
loop runs through this aforementioned table, setting the CSL registers
according to the table. However, this loop loops on CSL index values > 0:
while (csu_setting->csu_index *>* 0) {
io_write32(csu_base + (csu_setting->csu_index * 4),
csu_setting->value);
csu_setting++;
}
I think it should loop on CSL index values >= 0, because index 0 is a valid
index, utilized for the PWM peripherals. (I also think csl_index is a more
descriptive name, but that's besides the point).
I have attached a patch for his.
With kind regards,
Robert.
--
DISCLAIMER
De informatie, verzonden in of met dit e-mailbericht, is
vertrouwelijk en uitsluitend voor de geadresseerde(n) bestemd. Het gebruik
van de informatie in dit bericht, de openbaarmaking, vermenigvuldiging,
verspreiding en|of verstrekking daarvan aan derden is niet toegestaan.
Gebruik van deze informatie door anderen dan geadresseerde(n) is strikt
verboden. Aan deze informatie kunnen geen rechten worden ontleend. U wordt
verzocht bij onjuiste adressering de afzender direct te informeren door het
bericht te retourneren en het bericht uit uw computersysteem te verwijderen.