Constify mbedtls_cipher_supported

[XavierChapron]

Description

Constify cipher_wrap:mbedtls_cipher_supported

This structure can be initialized during the compilation and there is no reason it changes after that.
Making it const allows the compiler to put it in .rodata section instead of .bss one.

This also spares a few bytes in .text section by simplifying mbedtls_cipher_list().

Discussed with @gilles-peskine-arm here Mbed-TLS/TF-PSA-Crypto#261 (comment)

PR checklist

• changelog not required because: This doesn't fix anything relevant
• development PR not required because: This is going to be refactored
• TF-PSA-Crypto PR not required because: It doesn't apply
• framework PR not required
• 3.6 PR provided: This is the one.
• tests not required because: Already included in cipher tests build.

[gilles-peskine-arm]

Functionally, LGTM.

I used this code to validate the list (the left-hand side of the pipe can also be used to update it):

<library/cipher_wrap.c perl -l -ne 'next unless /mbedtls_cipher_definitions\[\] =/../^\}/; print if /^[#{}]/; print "    $1" if /\{ *(MBEDTLS_\w+,)/' | diff - <(perl -l -ne 'print if /mbedtls_cipher_supported\[/../^\}/' library/cipher_wrap.c)

---

However, now that I look at the result, I'm not so sure this is desirable. This saves some code, but also increases rodata by the same amount that is saved in BSS. So the binary is larger if there are many ciphers. The threshold depends on the code size that is saved. With (one particular version of) arm-none-eabi-gcc -mthumb -mcpu=cortex-m0plus -Os, I see 40 bytes saved in cipher.o. Each entry in the list is 4 bytes, so this is a win (in terms of binary size) only if there are 10 ciphers or less. I would guess that constrained applications are typically under 10 entries, but even then the savings aren't great.

[gilles-peskine-arm]

Could this go in cipher.c and be static? (And maybe save a few bytes by not giving it external linkage.)

[XavierChapron]

However, now that I look at the result, I'm not so sure this is desirable. This saves some code, but also increases rodata by the same amount that is saved in BSS. So the binary is larger if there are many ciphers. The threshold depends on the code size that is saved. With (one particular version of) arm-none-eabi-gcc -mthumb -mcpu=cortex-m0plus -Os, I see 40 bytes saved in cipher.o. Each entry in the list is 4 bytes, so this is a win (in terms of binary size) only if there are 10 ciphers or less. I would guess that constrained applications are typically under 10 entries, but even then the savings aren't great.

That's up to you. As discussed here the saving is indeed not great in binary size (and if you have too many cipher, the binary size even increase) however, the RAM usage always decrease.

As also mentioned in the other PR, this is interesting only if:

• the application is constraint in RAM size
• the application either call mbedtls_cipher_list() or don't use -ffunction-sections linker option

And in my opinion, in that case, the real problem is not what this PR fixes.