Closed Emantor closed 3 years ago
Hi,
Running xtest shows several errors, I think those are related to the strict TA parameter checking which was recently introduced (OK lines removed)
xtest
was updated in https://github.com/OP-TEE/optee_test/pull/446/commits, are you using an older version?
I have double checked this, my filesystem manifest says I have installed 3.11.0-rc1, which has SRCREV=159e295d5cc3ad2275ab15fe544620f6604d4ba4
pointing to the current head of the OP-TEE testsuite.
Additionally I build the optee-test from a local git checkout, adding a single line to the usage output of xtest to verify the correct binary is contained in the image. This unfortunately produces the same output as above.
Reverting https://github.com/OP-TEE/optee_client/commit/2de7f2531b704b83f9a44429cbab282df9b984a4 in the optee_client repository fixes my test failures.
I doubt this is a 32-bit problem. To me it looks like it has something to do with the shared memory configuration. What is common on these failing platforms?
For info, I'm running back xtest on stm32mp1 against latest optee_{client,os,test}. No issue so far:
# xtest
(...)
24426 subtests of which 0 failed
91 test cases of which 0 failed
0 test cases were skipped
TEE test application done!
Note I test over Linux v5.9. I'll test back with optee's kernel (latest optee branch from linaro-swg/linug.git) and will tell you if I see something wrong.
@Emantor, which commit for optee_os.git are you based on?
SRCREV = "009a14d6dcc77d8a321464e9e6d6de92dd297b4f"
so 009a14d6dcc77d8a321464e9e6d6de92dd297b4f.
Is this another bootloader issue? I'll look into it later today.
FWIW I am running kernel 5.8.7. I can definitely try kernel v5.9. Looking at the kernel diff, nothing immediate jumps out to me.
Following up on Jens' comment: does OP-TEE know about the whole non-secure memory which the client library might use to pass parameters to the TEE? It needs to be declared via register_dynamic_shm()
or via the DT.
Do the test pass if you rebuild with CFG_CORE_DYN_SHM=n
?
I can confirm this same issue when testing on qemuarm64, and it works fine after reverting the optee_client change that was suggested earlier (https://github.com/OP-TEE/optee_client/commit/2de7f2531b704b83f9a44429cbab282df9b984a4).
Tested again on qemuarm64 with CFG_CORE_DYN_SHM=n
and I still get the failures:
regression_1021.1 FAILED first error at /usr/src/debug/optee-test/3.10.0-r0/git/host/xtest/regression_1000.c:1644
regression_1021.2 FAILED first error at /usr/src/debug/optee-test/3.10.0-r0/git/host/xtest/regression_1000.c:1644
regression_1021.3 FAILED first error at /usr/src/debug/optee-test/3.10.0-r0/git/host/xtest/regression_1000.c:1644
regression_1021.4 FAILED first error at /usr/src/debug/optee-test/3.10.0-r0/git/host/xtest/regression_1000.c:1719
regression_4002.35 FAILED first error at /usr/src/debug/optee-test/3.10.0-r0/git/host/xtest/regression_4000.c:259
regression_4005.7 FAILED first error at /usr/src/debug/optee-test/3.10.0-r0/git/host/xtest/regression_4000.c:536
regression_4006.1 FAILED first error at /usr/src/debug/optee-test/3.10.0-r0/git/host/xtest/regression_4000.c:631
regression_4007_symmetric.1 FAILED first error at /usr/src/debug/optee-test/3.10.0-r0/git/host/xtest/regression_4000.c:802
regression_4007_symmetric.2 FAILED first error at /usr/src/debug/optee-test/3.10.0-r0/git/host/xtest/regression_4000.c:802
regression_4007_symmetric.3 FAILED first error at /usr/src/debug/optee-test/3.10.0-r0/git/host/xtest/regression_4000.c:802
regression_4007_symmetric.4 FAILED first error at /usr/src/debug/optee-test/3.10.0-r0/git/host/xtest/regression_4000.c:802
regression_4007_symmetric.5 FAILED first error at /usr/src/debug/optee-test/3.10.0-r0/git/host/xtest/regression_4000.c:802
regression_4007_symmetric.6 FAILED first error at /usr/src/debug/optee-test/3.10.0-r0/git/host/xtest/regression_4000.c:802
regression_4007_symmetric.7 FAILED first error at /usr/src/debug/optee-test/3.10.0-r0/git/host/xtest/regression_4000.c:802
regression_4007_symmetric.8 FAILED first error at /usr/src/debug/optee-test/3.10.0-r0/git/host/xtest/regression_4000.c:802
regression_4007_symmetric.9 FAILED first error at /usr/src/debug/optee-test/3.10.0-r0/git/host/xtest/regression_4000.c:802
regression_4007_symmetric.10 FAILED first error at /usr/src/debug/optee-test/3.10.0-r0/git/host/xtest/regression_4000.c:802
regression_4007_rsa.1 FAILED first error at /usr/src/debug/optee-test/3.10.0-r0/git/host/xtest/regression_4000.c:802
regression_4011 FAILED first error at /usr/src/debug/optee-test/3.10.0-r0/git/host/xtest/regression_4000.c:802
regression_6012.1 FAILED first error at /usr/src/debug/optee-test/3.10.0-r0/git/host/xtest/regression_6000.c:1380
regression_6012.2 FAILED first error at /usr/src/debug/optee-test/3.10.0-r0/git/host/xtest/regression_6000.c:1380
regression_6017.1 FAILED first error at /usr/src/debug/optee-test/3.10.0-r0/git/host/xtest/regression_6000.c:1629
regression_6017.2 FAILED first error at /usr/src/debug/optee-test/3.10.0-r0/git/host/xtest/regression_6000.c:1629
regression_6018.1 FAILED first error at /usr/src/debug/optee-test/3.10.0-r0/git/host/xtest/regression_6000.c:1697
regression_6018.2 FAILED first error at /usr/src/debug/optee-test/3.10.0-r0/git/host/xtest/regression_6000.c:1697
12825 subtests of which 51 failed
91 test cases of which 10 failed
0 test cases were skipped
TEE test application done!
Path is 3.10 but this is latest 3.11-rc1.
So I guess in my case optee is not declaring the all the non-secure memory via register_dynamic_shm during init (which should explain why it works for a few targets but not all).
For a standard QEMU v8 configuration I just tested successfully with:
mkdir qemu_v8
cd qemu_v8
repo init -u https://github.com/OP-TEE/manifest.git -m qemu_v8.xml
repo sync
cd build
make toolchains
make all
make run-only
Are you using some odd configuration?
Hello. Just for the record: I'm seeing exactly the same issues on Rcar Gen3 which is arm64 platform.
Main difference is that I'm using OpenEmbedded and the qemuarm64 target machine.
Using QEMU 5.1.0, ATF 2.3, OP-TEE 3.11.0-rc1, U-Boot 2020.04 and Kernel 5.8.13 (built with GCC 10.2).
make PLATFORM=vexpress-qemu_armv8a CROSS_COMPILE_core=aarch64-lmp-linux- CFG_WERROR=y DEBUG=0 LDFLAGS= CFG_TEE_CORE_LOG_LEVEL=2 CFG_TEE_TA_LOG_LEVEL=2 CFG_ARM64_core=y CROSS_COMPILE_ta_arm64=aarch64-lmp-linux- ta-targets=ta_arm64
qemu-system-aarch64 -device virtio-net-device,netdev=net0,mac=52:54:00:12:35:02 -netdev user,id=net0,hostfwd=tcp::2222-:22 -drive id=disk0,file=lmp-base-console-image-qemuarm64.wic,if=none,format=raw -device virtio-blk-device,drive=disk0 -no-acpi -bios flash.bin -nographic -machine virt,secure=on -cpu cortex-a57 -m 1024 -serial tcp:localhost:54320,server,nowait -serial tcp:localhost:54321,server,nowait -S
Also had a similar issue with zynqmp-zcu102 (CFG_CORE_DYN_SHM is disabled by default).
The key difference is that 185d7548c968 ("driver: tee: Handle NULL pointer indication from client") is missing in the failing cases. So there's an error in OP-TEE/optee_client@2de7f25, I'd prefer a proper fix over reverting that commit.
@jenswi-linaro, I cherry-picked mentioned patch to the mainline 5.9 kernel and I still can see that the same tests are failing.
All other components (optee_os
, optee_client
, optee_test
) are at 3.11.0-rc1
Jens, please disregard my previous message. I have found that I copied test TAs into wrong place, so xtest
ran with TAs from another build.
Your patch for kernel really fixes the issue.
@jenswi-linaro , for the NULL pointer handling, are you referring to the use case where tmpref->buffer is NULL and ctx->memref_null is not set ? In that particular scenario, TEEC_RegisterSharedMemory would fail and as per flow before this patch, we should use the TEEC_AllocateSharedMemory. I am not sure I understand how this will work.
If someone passes a NULL pointer as a buffer and ctx->memref_null is not set, calling TEEC_AllocateSharedMemory will return a temporary buffer. But how do you copy from a NULL pointer to this buffer ? So, I don't understand how this temporary buffer will be used.
I can add a patch to add the flow for this. However, I am not sure if this is a valid scenario ?Also, I see that OPTEE_SMC_SEC_CAP_MEMREF_NULL is always set as a capability from optee-os. So if you have the right linux driver, the above situation will never happen .
@ruchi393, I haven't looked close enough at what's going in in optee_client. But I expect that all tests that doesn't involve testing NULL pointer behaviour should pass with or without ctx->memref_null
being true.
I will send a patch of the missing case.
I have raised a PR - https://github.com/OP-TEE/optee_client/pull/221
Please check if it fixes the issue in your environment. At my end , in my build environment for QEMU ARMv8, I reverted the linux patch (185d7548c968 ("driver: tee: Handle NULL pointer indication from client") and gave this fix a try. It does seem to fix the issues.
Running xtest shows several errors, I think those are related to the strict TA parameter checking which was recently introduced (OK lines removed):
1021:
4002.35:
4005.7:
4006.1:
4007_symmetric:
4007_rsa:
6009:
6010:
6012:
6017:
6018: