lib: uuid: libraries.uuid.base fails

[katgiadla]

Describe the bug
The test tests/lib/uuid/libraries.uuid.base fails.

Observed for

• nrf5340dk/nrf5340/cpuapp/ns
• nrf9160dk@0.14.0/nrf9160/ns

To Reproduce
Steps to reproduce the behavior:

1. have nrf5340dk/nrf5340 connected
2. go to your zephyr dir
3. call ./scripts/twister -s libraries.uuid.base -p nrf5340dk/nrf5340/cpuapp/ns --device-testing --device-serial /dev/ttyACM1 -v --inline-logs --west-flash="--erase"
4. See console output with error

Expected behavior
Valid console output

Impact
Not clear

Logs and console output

*** Booting Zephyr OS build v4.1.0-3563-gd26ed348ef21 ***
Running TESTSUITE uuid
===================================================================
START - test_uuid_copy
 PASS - test_uuid_copy in 0.001 seconds
===================================================================
START - test_uuid_from_buffer
 PASS - test_uuid_from_buffer in 0.001 seconds
===================================================================
START - test_uuid_from_string
 PASS - test_uuid_from_string in 0.001 seconds
===================================================================
START - test_uuid_from_string_errors
 PASS - test_uuid_from_string_errors in 0.001 seconds
===================================================================
START - test_uuid_to_base64
 PASS - test_uuid_to_base64 in 0.001 seconds
===================================================================
START - test_uuid_to_base64url
 PASS - test_uuid_to_base64url in 0.001 seconds
===================================================================
START - test_uuid_to_buffer
 PASS - test_uuid_to_buffer in 0.001 seconds
===================================================================
START - test_uuid_to_string
 PASS - test_uuid_to_string in 0.001 seconds
===================================================================
START - test_uuid_v4
 SKIP - test_uuid_v4 in 0.001 seconds
===================================================================
START - test_uuid_v5

    Assertion failed at zephyr/tests/lib/uuid/src/main.c:40: uuid_test_uuid_v5: (result == 0 is false)
uuid_generate_v5 returned an error
 FAIL - test_uuid_v5 in 0.015 seconds
===================================================================
TESTSUITE uuid failed.

------ TESTSUITE SUMMARY START ------

SUITE FAIL -  88.89% [uuid]: pass = 8, fail = 1, skip = 1, total = 10 duration = 0.024 seconds
 - PASS - [uuid.test_uuid_copy] duration = 0.001 seconds
 - PASS - [uuid.test_uuid_from_buffer] duration = 0.001 seconds
 - PASS - [uuid.test_uuid_from_string] duration = 0.001 seconds
 - PASS - [uuid.test_uuid_from_string_errors] duration = 0.001 seconds
 - PASS - [uuid.test_uuid_to_base64] duration = 0.001 seconds
 - PASS - [uuid.test_uuid_to_base64url] duration = 0.001 seconds
 - PASS - [uuid.test_uuid_to_buffer] duration = 0.001 seconds
 - PASS - [uuid.test_uuid_to_string] duration = 0.001 seconds
 - SKIP - [uuid.test_uuid_v4] duration = 0.001 seconds
 - FAIL - [uuid.test_uuid_v5] duration = 0.015 seconds

------ TESTSUITE SUMMARY END ------

===================================================================
PROJECT EXECUTION FAILED

Environment (please complete the following information):

• OS: Ubuntu 20.04.1 LTS
• Toolchain Zephyr SDK 0.17.0
• Commit SHA or Version used: 5fb47cd

Additional information:
Probably introducedy by commit dfd0dd0

[nordic-piks]

Possible fixed by 9bbccf3

Not fixed by that commit

[carlescufi]

@dantti would you mind checking this failure?

[dantti]

I can try next week, would testing on an ESP32 work? that's the only thing I have, still it would be really odd if my change break these tests, @katgiadla did you git bisect?

[carlescufi]

I can try next week, would testing on an ESP32 work?

Sure, that works. Hopefully we can repro this with another SoC. If not I will look at it myself, since I obviously have the board (I work for Nordic).

[katgiadla]

@katgiadla did you git bisect?

yes, I have done git bisect

update: I've bisected once again and update commit, which could be probably root cause of issue.

[carlescufi]

@tomi-font the bisected SHA points to a TF-M update, could this be causing the failure?

[tomi-font]

@tomi-font the bisected SHA points to a TF-M update, could this be causing the failure?

Interesting. Not impossible, though I'm wondering how could TF-M influence the UUID library. I can have a look at some point.

[tomi-font]

I looked into this, and indeed the test starts failing after the TF-M update. The TF-M update updates Mbed TLS to 3.6.3 in TF-M, which brings some changes to the configuration of the MD module in Mbed TLS: https://github.com/zephyrproject-rtos/trusted-firmware-m/pull/130/files#diff-f099753872f927fda4221b05411176ec1197002d8f2d4d58399de5ee02edb02bR54-R169

The failing test tests uuid_generate_v5(), which needs to use SHA-1.
With the changes coming from Mbed TLS it results in MD calling psa_hash_*() to perform the operations, which means the calls now go to TF-M.
But in TF-M SHA-1 is disabled in all the profiles, and I don't think we currently have a way to pass single configurations to TF-M (PSA_WANT_ALG_SHA_1), so it looks like there's currently no way to enable SHA-1 in TF-M.
Also, CONFIG_MBEDTLS_PSA_CRYPTO_C cannot be enabled when TF-M is enabled (and this would really just be a workaround).
Looks like the only, proper way to solve this would be to allow passing PSA Crypto configs to TF-M. (Or modifying the behavior that was just changed in Mbed TLS).

@valeriosetti, as it's your commit which introduced the behavior change in Mbed TLS and I think you have been in talks of improving the Zephyr => TF-M configuration, maybe there's something you could do here? Or if you have other solution suggestions?

In the meantime this failure is "expected".

[valeriosetti]

@valeriosetti, as it's your commit which introduced the behavior change in Mbed TLS and I think you have been in talks of improving the Zephyr => TF-M configuration, maybe there's something you could do here? Or if you have other solution suggestions?

Sorry for the delay, but I just looked at this now.
Yes, the problem is that Mbed TLS' MD module can now dispatch to PSA also when MBEDTLS_PSA_CRYPTO_CLIENT is set (which is in case of a TF-M build) and that in TF-M there is no support of SHA-1. One solution is surely to pass PSA_WANT_xxx from Zephyr down to TF-M at build time. This would be really cool and I would really like to look into that, but it will take some time unfortunately...

Side note: UUID library should not use mbedtls_md_xxx() functions, but it should rely directly on PSA Crypto. Not that this will solve the problem (again, no SHA-1 in TF-M), but it would have made the problem easier to identify (no need required on MD's internal magic).

[valeriosetti]

Based on the discussion above I created #90372 to prevent this test from being executed on TF-M platforms.

[carlescufi]

Thanks @tomi-font and @valeriosetti for the analysis and fix.