Update CHANGELOG for 3.9.0

[jenswi-linaro]

Update CHANGELOG for 3.9.0 and collect Tested-by tags.

Signed-off-by: Jens Wiklander [email protected]

[jforissier]

We still have quite a few PRs pending, but anyway I have tested the master branch at commit f267456 ("libutee: crypto: AE: Explicitly initialize buffer_offs") and all is good:

Tested-by: Jerome Forissier <[email protected]> (HiKey960, GP)
Tested-by: Jerome Forissier <[email protected]> (QEMUv8)

[Emantor]

xtest -l 15
+-----------------------------------------------------
44600 subtests of which 0 failed
99 test cases of which 0 failed
0 test cases were skipped
TEE test application done!

Tested-by: Rouven Czerwinski <[email protected]> (mx6qsabrelite)

[lorc]

@jenswi-linaro, @jforissier, I'm interested about policy regarding features/fixes that are not upstreamed yet.

Right now I see 3 fails in xtest:

regression_1027 FAILED first error at /home/lorc/work/optee_test/host/xtest/regression_1000.c:2124 
regression_1028 FAILED first error at /home/lorc/work/optee_test/host/xtest/regression_1000.c:2174
regression_2002.1 FAILED first error at /home/lorc/work/optee_test/host/xtest/regression_2000.c:540 

1027 and 1028 are failing because my kernel does not support REE login feature. And 2002 is failing because of a bug in TEE mediator in Xen. I'll already published the patch, but it is not upstreamed yet. As far as I know, REE login methods are also not in mainline.

Anyways, I'm building setup with mentioned patches, and xtest will pass eventually. So, there is no bugs in OP-TEE OS per se, but OP-TEE OS depends on another components, which are not in the final form. Especially this affects REE login, is it is not merged in Linux mainline, so theoretically there is a chance that API/ABI for this feature will change during discussions.

So, back to my question. What should I report in this PR? That there are fails when using latest mainline components, or all is fine, but user need to cherry-pick some patches manually?

[lorc]

Also, please take a look at linaro-swg/linux#77

[jforissier]

Hi @lorc, thanks for testing.

Regarding 1027/1028. Generally speaking, and for simplicity, xtest assumes latest OP-TEE and latest kernel from linaro-swg/linux branch optee. In most cases, upstream Linux should work fine too because we try to upstream as much and as quickly as possible (if you look at the difference between our optee branch and upstream, you will seem mainly some DTS files and the "secure data path" feature based on ION which never made its way upstream). Ideally patches should go "upstream first", but for non-trivial patches they are discussed in PR in linaro-swg/linux first. I do not always wait for the patches to land upstream before merging them into the optee branch, because it allows us to get going quicker (CI builds etc.) and once Jens has acked a patchset there is not much doubt it will finally get merged. But I agree there is no guarantee.

As for 2002.1: does it mean we have a regression between 3.8.0 and latest when a non-patched Xen is used?

So, back to my question. What should I report in this PR? That there are fails when using latest mainline components, or all is fine, but user need to cherry-pick some patches manually?

Your report is excellent :)

[lorc]

As for 2002.1: does it mean we have a regression between 3.8.0 and latest when a non-patched Xen is used?

No, it is not a regression. The bug in Xen always was there. I don't know exactly why it didn't reproduced before.

It is all about timings. Basically, Xen is stricter than necessary when dealing with shared buffers. Looks like some recent changes to SHM code in OP-TEE or in the linux driver revealed this issue.

[igoropaniuk]

+-----------------------------------------------------
24789 subtests of which 0 failed
103 test cases of which 0 failed
0 test cases were skipped
TEE test application done!

Tested-by: Igor Opaniuk <[email protected]> (Poplar)

[jenswi-linaro]

Tested-by: Jens Wiklander <[email protected]> (Juno)

[jenswi-linaro]

Tested-by: Jens Wiklander <[email protected]> (Hikey)

[jenswi-linaro]

With #3867
Tested-by: Jens Wiklander <[email protected]> (FVP)

[jenswi-linaro]

I've tagged 3.9.0-rc1

[etienne-lms]

For 3.9.0-rc1:
Tested-by: Etienne Carriere <[email protected]> (qemu_virt/qemu_armv8)

For 3.9.0-rc1 + #3866:
Tested-by: Etienne Carriere <[email protected]> (stm32mp1)

I suggest also #3856 be part of tag 3.9.0.

[b49020]

For 3.9.0-rc1 and using linaro-swg/linux branch optee:
Tested-by: Sumit Garg <[email protected]> (Developerbox)

xtest -l 15
...
+-----------------------------------------------------
44621 subtests of which 0 failed
102 test cases of which 0 failed
0 test cases were skipped
TEE test application done!

And regarding 1027/1028, I got the same failures as pointed by @lorc with my Developerbox booting stable kernel 5.4 which is due to stable kernel missing REE login feature. So wouldn't it be a good practice to test a certain feature if its supported by underlying kernel (especially on stable kernels where people may not want to backport feature as such) rather than giving false failures? I am not saying that it should be blocker for this release but something we can consider for future releases.

[etienne-lms]

Maybe an added xtest option --kernel-version for such situations to disable tests that don't comply recently merge changes in linaro/linux.git opee branch. File upstream-tee-subsys-patches.txt provides the patches per kernel version. Here from "v4.5" to "v5.7" would disable 1027/1028.

[etienne-lms]

Build warning foudn in optee_test. Propose fix with OP-TEE/optee_test#426. To consider in tag 3.9.0.

Regarding 1027/1028 failing with mainline kernels, I propose OP-TEE/optee_test#424 to handle such situations.

[clementfaure]

Hello, for 3.9.0-rc1 :

Tested-by: Clement Faure <[email protected]> (mx6dlsabreauto)
Tested-by: Clement Faure <[email protected]> (mx6qpsabreauto)
Tested-by: Clement Faure <[email protected]> (mx6dlsabresd)
Tested-by: Clement Faure <[email protected]> (mx6ulevk)
Tested-by: Clement Faure <[email protected]> (mx6ullevk)
Tested-by: Clement Faure <[email protected]> (mx6ulzevk)
Tested-by: Clement Faure <[email protected]> (mx6slevk)
Tested-by: Clement Faure <[email protected]> (mx6sllevk)
Tested-by: Clement Faure <[email protected]> (mx7dsabresd)
Tested-by: Clement Faure <[email protected]> (mx7ulpevk)
Tested-by: Clement Faure <[email protected]> (mx8mmevk)
Tested-by: Clement Faure <[email protected]> (mx8mnevk)
Tested-by: Clement Faure <[email protected]> (mx8mqevk)
Tested-by: Clement Faure <[email protected]> (mx8qxpmek)

[jbech-linaro]

Gave RPi3 a try:

# xtest -l 15
...
Result of testsuite regression:
...
regression_1027 FAILED first error at regression_1000.c:2125
regression_1028 FAILED first error at regression_1000.c:2181
...
44621 subtests of which 2 failed
102 test cases of which 2 failed
0 test cases were skipped
TEE test application done!

Seems to build down to a memcmp not getting expected results.

memcmp(&expected_client_uuid, &client_uuid, sizeof(TEEC_UUID)) has an unexpected value: 0x1, expected 0x0

Log from 1027,1028 run separately can be found here.

[jenswi-linaro]

Gave RPi3 a try:

The error looks like some missing kernel patches. RPi3 doesn't use https://github.com/linaro-swg/linux?

[jforissier]

@jbech-linaro @jenswi-linaro the reason is linaro-swg/linux#75 is not merged, my mistake 😞
@jbech-linaro can you try again with that PR, and I'll merge when you confirm it's OK?

[jbech-linaro]

@jbech-linaro can you try again with that PR, and I'll merge when you confirm it's OK?

Sure, I'll get back once tested.

[jbech-linaro]

RPi3 doesn't use https://github.com/linaro-swg/linux?

It doesn't, it uses a fork from the Raspberry Pi folks. Which of course is a fork of Linux. Our fork is here: https://github.com/linaro-swg/linux/tree/rpi3-optee-4.14

Btw, I have a setup where Linux is based on the Raspberry Pi folks 4.19 kernel that is working (or I should say it worked ~1 month ago, haven't tried since then). However IIRC I also had to make some changes to Buildroot to make that work.

[jbech-linaro]

@jbech-linaro can you try again with that PR, and I'll merge when you confirm it's OK?

Sure, I'll get back once tested.

Unfortunately I get a bunch of compiler errors (http://ix.io/2mGr) when applying linaro-swg/linux#75.

[jforissier]

@jbech-linaro can you try again with that PR, and I'll merge when you confirm it's OK?

Sure, I'll get back once tested.

Unfortunately I get a bunch of compiler errors (http://ix.io/2mGr) when applying linaro-swg/linux#75.

Ah, I see. Some previous patches are missing. At least https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e2aca5d8928acb9cc9a87802b02102d4f9b9b596.

I'll try to fix that up.

[jforissier]

3.9.0-rc1 with #3873 and #3875:

Tested-by: Jerome Forissier <[email protected]> (HiKey, GP)

root@HiKey:/ xtest
...
29280 subtests of which 0 failed
748 test cases of which 0 failed
0 test cases were skipped
TEE test application done!

I have tested several 64/32 bit combinations with various CFG_ flags as usual.

[jforissier]

@jbech-linaro can you try again with that PR, and I'll merge when you confirm it's OK?

Sure, I'll get back once tested.

Unfortunately I get a bunch of compiler errors (http://ix.io/2mGr) when applying linaro-swg/linux#75.

Ah, I see. Some previous patches are missing. At least https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e2aca5d8928acb9cc9a87802b02102d4f9b9b596.

I'll try to fix that up.

@jbech-linaro PR 75 updated, can you try again? The kernel now builds properly at least.

[jbech-linaro]

@jbech-linaro PR 75 updated, can you try again? The kernel now builds properly at least.

Thanks, I'll give it a try. Stay tuned!

[jforissier]

3.9.0-rc1:

Tested-by: Jerome Forissier <[email protected]> (QEMUv8)

[clementfaure]

Here is another one for 3.9.0-rc1:
Tested-by: Clement Faure <[email protected]> (mx8qmmek)

[jbech-linaro]

With Jerome's fixes in linaro-swg/linux#75 (thanks @jforissier!)

+-----------------------------------------------------
44621 subtests of which 0 failed
102 test cases of which 0 failed
0 test cases were skipped
TEE test application done!

Tested-by: Joakim Bech <[email protected]> (RPi3)

[etienne-lms]

Tested Qemu with the GP test suite:
on Qemu armv7 with and without pager
on Qemu armv8, core/TAs 32b, Core 64b/TAs 32b and core/TAs 64b.
Tested on 3.9.0-rc1 + with optee_os latest master (c3682b1)
+ with or and without #3873 & #3875

Tested-by: Etienne Carriere <[email protected]> (Qemu armv7/armv8 + GP)

(edited: remove info below, I messed with the -Werror-* and friends directives)
(note: to build GP tests with GCC 8.3, I had to hack a bit in the xtest xml files and CMake scripts, I can provide a P-R if needed)

[jbech-linaro]

Tested-by: Joakim Bech <[email protected]> (RPi3-NFS)

# xtest -l 15
...
44621 subtests of which 0 failed
102 test cases of which 0 failed
0 test cases were skipped
TEE test application done!

[lorc]

With backported kernel patches:

Tested-by: Volodymyr Babchuk <[email protected]> (Rcar H3)
With fixes to Xen:
Tested-by: Volodymyr Babchuk <[email protected]> (Rcar H3/virtualization)