From the perspective of an application developer whose platform doesn't
have a native malloc, the advantage for Mbed TLS to include its own malloc is one less dependency to integrate (so one less source of potential incompatibilities, one less component to integrate into the build, one less set of parameters to configure, one less feed of security updates to keep up with, etc.).
I expect that choosing the Mbed TLS allocator would give poorer performance and higher RAM consumption than choosing the best allocator that exists out there. But it gives better time to market, and potentially a better security posture (the highest-performance allocator may or may not turn out to be actively maintained).
-- Gilles Peskine Mbed TLS developer
On 16/04/2020 14:19, Janos Follath via mbed-tls wrote:
Hi,
Thank you for sharing your view, it makes perfect sense.
You mention that you would consider keeping the module internally for the sake of baremetal applications. How would this serve the user better than choosing a third party malloc implementation? (Assuming that there are better implementation out there than ours, which I haven't confirmed, but it is not hard to imagine that such exists.)
Regards, Janos
On 15/04/2020, 21:11, "mbed-tls on behalf of Gilles Peskine via mbed-tls" <mbed-tls-bounces@lists.trustedfirmware.org on behalf of mbed-tls@lists.trustedfirmware.org> wrote:
On 09/04/2020 13:17, Janos Follath via mbed-tls wrote: > Hi, > > Based on what I read on this thread it seems an accepted point of view that the toolchain provided C standard library implementations are less trusted than the toolchains themselves. Can somebody please help me understand the reasoning behind this distinction? Well, I disagree with this statement. I trust the toolchain to implement the C standard library correctly, and with good performance for the target platform. I do not want to provide my own implementation of standard functions. I only trust the toolchain to be functionally correct. I don't know about its security. I certainly can't rely on the toolchain to have security characteristics that are not guaranteed by the language definition. For example, I do trust memset_s() to zero out sensitive memory if the toolchain provides it, but I don't trust memset() for this task. On the topic at hand, my personal opinion of memory_buffer_alloc is that it doesn't belong in Mbed TLS. I hope that when PSA crypto is a standalone product, it won't use malloc internally, and so it certainly won't provide a malloc implementation. I wouldn't necessarily say the same thing of Mbed TLS 4.0: it's difficult to design an X.509 interface that doesn't use malloc. But if we can do it, I think we should. I recognize that there are many bare-metal applications that don't use malloc themselves, but use Mbed TLS. For their sake, it does make some sense for Mbed TLS to have its own malloc implementation. But the focus is for internal use, not on serving as a general-purpose allocator for applications that also use malloc for non-mbedtls-related purposes. -- Gilles Peskine Mbed TLS developer 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. -- 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.