Hello All, 

In our embedded platform, we are using static memory allocator, instead of using heap memory of the platform. 
We thought it is better way to handle the memory. As the application grows, there might be multiple libraries using the heap memory. And also the possible cause of memory leaks. 
My suggestion is that it is better to have it. 
I have seen this kind of allocator in mocona secure library also. 

Thanks


On Wed, Apr 8, 2020 at 4:11 PM Manuel Pegourie-Gonnard via mbed-tls <mbed-tls@lists.trustedfirmware.org> wrote:
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