Hi, I think this is related to the more general need for an implementation of the C standard library for trusted firmware projects. As far as I know TF-A and TF-M don't use the standard library provided by compilation toolchains. The rationale is to have complete control over the trusted firmware code. Currently they both have their own partial implementation of the parts of the C standard library they need.

This memory_buffer_alloc.c module in question here is another partial implementation of the C standard library. Currently TF-A and TF-M don't use/provide dynamic memory allocations but PSA-FF explicitly mentions that an SPM implementation may support dynamic memory allocation. Thus it is possible that TF-M at some point consider providing dynamic memory allocation support.

All of this to say that a possible way forward may be to remove memory_buffer_alloc.c from the code base when there is a C standard library implementation common to trustedfirmware.org projects (is there already a security oriented open source implementation out there ?).

In Mbed TLS, it would also make sense to me to, by default, not use C standard libraries provided by compilation toolchains (MBEDTLS_PLATFORM_NO_STD_FUNCTIONS defined by default).

Thanks, Ronald.

-----Original Message----- From: mbed-tls mbed-tls-bounces@lists.trustedfirmware.org On Behalf Of Manuel Pegourie-Gonnard via mbed-tls Sent: 08 April 2020 12:42 To: mbed-tls@lists.trustedfirmware.org Cc: nd nd@arm.com Subject: [mbed-tls] 3.0 plans: remove memory_buffer_alloc.c from the code base

Hi all,

In this new installment of "let's discuss ideas for Mbed TLS 3.0" [1]: should we remove memory_buffer_alloc.c from the code base?

[1]: https://developer.trustedfirmware.org/w/mbed-tls/tech-plans-3.0/

Currently the crypto library includes a module called memory_buffer_alloc.c, disabled in the default build (config.h option MBEDTLS_MEMORY_BUFFER_ALLOC_C), which provides implementations of calloc() and free() based on a user-provided buffer (which could be static or on the stack), suitable for use in the rest of the crypto, X.509 and TLS libraries as replacements to the standard functions.

In addition to providing replacement calloc() and free(), the module also offers some facilities for measurement and debugging.

We're considering dropping this module and removing it from the code base entirely for the following reasons:

- Memory allocators are not our core area of expertise.

- This allocator is pretty basic and has a large allocation overhead. For example for ECC computations, the overhead can be as large as the actual memory used.

- Using this allocator also tends to slow things down, so we don't run many tests with it enabled.

- In the future when we split between PSA Crypto on one side and Mbed TLS and X.509 on the other, it's unclear on which side this allocator should fall. Which can be taken as a sign that it doesn't really belong here.

On the other hand, we're hesitating for the following reasons:

- We know from bug reports and questions that some people are using it.

- Unlike other modules we'd like to drop, there isn't a strong security incentive to dropping this allocator, it's merely a matter of how we spend our maintenance resources.

What do you think? Should we keep maintaining this allocator as part of Mbed TLS? Should we drop it and focus on our core instead? If you're using this allocator, why did you pick it over other alternatives?

Regards, Manuel. -- mbed-tls mailing list mbed-tls@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.