Re: [mbed-tls] 3.0 plans: remove memory_buffer_alloc.c from the code base

9 Apr 2020

      Hi Janos
It's not so much that the toolchain stdlib implementations are less trusted from a security point of view, it's that there is variation in their non-functional characteristics, e.g.
* security
* robustness
* code size
* performance
* open-ness
* ...
If you remove this variation it's easier to reason about the non-functional characteristics of the code. This is perhaps more important for projects that build final executable images but may also be important for libraries, especially ones that export executable link libraries like Mbed TLS.
On the other hand, Mbed TLS is deployed in many other places than Trusted Firmware and it may be hard to choose a stdlib implementation that works for all users. Perhaps the compromise is to create a shared stdlib implementation for Trusted Firmware deployments but leave the choice open for other Mbed TLS users?
Regards
Dan
...
-----Original Message-----
From: mbed-tls mbed-tls-bounces@lists.trustedfirmware.org On Behalf Of
Janos Follath via mbed-tls
Sent: 09 April 2020 12:18
To: mbed-tls@lists.trustedfirmware.org
Subject: Re: [mbed-tls] 3.0 plans: remove memory_buffer_alloc.c from the code
base
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?
Regards,
Janos
On 09/04/2020, 12:07, "Dan Handley via mbed-tls" <mbed-
tls@lists.trustedfirmware.org> wrote:
Hi

There has already been some discussion about a shared C standard library

implementation, at least for TF-A and TF-M. So far there's been general
agreement that this is a good idea but no actual commitment from anyone to
make this happen, since each project is reasonably happy with what they've
got.
Regarding MBEDTLS_MEMORY_BUFFER_ALLOC_C, TF-A at least enables this so

removing this from the codebase would be an issue there. Memory allocators
are probably not the core expertise of other Trusted Firmware projects either
but it needs to be if they're going to use them!
I propose that we move this allocator into a new shared

TrustedFirmware.org standard C library project and work with the other
projects to ensure it has the correct initial maintainers. This will probably
have to be driven by the maintainers of whichever project is most motivated
to make this happen. It sounds like that could be Mbed TLS and this will need
to be done before any separation of the PSA Crypto implementation. In the
short term, as we move C stdlib functionality out of the other projects and
into this new project, we will need to support multiple implementations of
some functions. Eventually we should move towards a common implementation,
and I agree we should look at what security-oriented implementations are
already available.
I also agree it would make sense for Mbed TLS to not use the toolchain-

provided stdlib implementation by default, but only once it uses a default
implementation it trusts.
Regards

Dan.

> -----Original Message-----
> From: mbed-tls <mbed-tls-bounces@lists.trustedfirmware.org> On Behalf

Of
    > Ronald Cron via mbed-tls
    > Sent: 09 April 2020 08:47
    > To: mbed-tls@lists.trustedfirmware.org
    > Subject: Re: [mbed-tls] 3.0 plans: remove memory_buffer_alloc.c from
the code
    > base
    >
    > 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.
    > --
    > 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.
    --
    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.
--
mbed-tls mailing list
mbed-tls@lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls

2024

2023

2022

2021

2020

Re: [mbed-tls] 3.0 plans: remove memory_buffer_alloc.c from the code base