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(a)lists.trustedfirmware.org> On Behalf Of Manuel Pegourie-Gonnard via mbed-tls
Sent: 08 April 2020 12:42
To: mbed-tls(a)lists.trustedfirmware.org
Cc: nd <nd(a)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(a)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.
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(a)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(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls
>
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.
Hi all,
In this new installment of "let's discuss ideas for Mbed TLS 3.0" [1]:
should we remove havege.c from the code base?
[1]: https://developer.trustedfirmware.org/w/mbed-tls/tech-plans-3.0/
The crypto library currently includes an implementation of the HAVEGE entropy
gatherer [2], which is disabled in the default build (MBEDTLS_HAVEGE_C in
config.h), but used as a source by our entropy module if enabled.
[2]: https://www.irisa.fr/caps/projects/hipsor/
We'd like to drop this module and remove it from the code base entirely for
the following reasons:
- HAVEGE was designed for superscalar processors with high
microarchitectural complexity, and is unsuitable for microcontrollers (or
virtualized environments). We feel like when a complex enough CPU is used for
HAVEGE to stand a chance of being secure, it's very likely that an operating
system is also available, which probably already manages a random generator
better that what we can do in user space.
- On a more practical note, our implementation relies on `timing_hardclock()`
provided by timing.c only for a limited number of architectures and
environments (funnily enough, not including any Arm architecture), with a
silent fallback to a definition relying on `gettimeofday()` which is clearly
not high-resolution enough to make HAVEGE secure.
- As with any random source, it is very difficult to assess whether HAVEGE is
actually secure on any given platform. Further, the maintenance team
doesn't have any specific knowledge of HAVEGE and there hasn't been any
independent evaluation of our implementation of it.
- As a result of the above points, we're afraid people using our HAVEGE
implementation on the wrong platforms, might be getting a false sense of
security, which might prevent them from using more secure options, such as the
OS RNG (when using an OS) or a hardware RNG (on microcontrollers).
If you're using MBEDTLS_HAVEGE_C or know someone who does, or if for any other
reason you think we shouldn't drop it in Mbed TLS 3.0, please speak up now!
Regards,
Manuel.
Hi all,
In this new installment of "let's discuss ideas for Mbed TLS 3.0" [1]:
should we remove pkcs11.c from the code base?
[1]: https://developer.trustedfirmware.org/w/mbed-tls/tech-plans-3.0/
The X.509 library currently includes a module called "pkcs11", excluded from
the default build, which provides a few wrappers around libpkcs11-helper [2],
a library that "simplifies the interaction with PKCS#11 providers for end-user
applications". In practice, it supports the use of X.509 certificates
associated with an RSA key (not ECDSA) managed by libpkcs11-helper.
[2]: https://github.com/OpenSC/pkcs11-helper
We'd like to drop this module and remove it from the code base entirely for
the following reasons:
- It has limited functionality, and soon PSA Crypto will provide more flexible
support for secure management of private keys (not just RSA, and not just
associated with X.509 certificates).
- It currently has not automated tests so we're not even sure if it still
works properly.
- The documentation is scarce and no member of the current maintenance team
knows for sure how it's supposed to work.
- We never receive any support request about it so we're not sure if anyone is
still using it. (As a weaker signal in the same direction, we deprecated it
in 2.21.0, released 2020-02-20, and nobody complained so far.)
If you're using MBEDTLS_PKCS11_C or know someone who does, or if for any other
reason you think we shouldn't drop it in Mbed TLS 3.0, please speak up now!
Regards,
Manuel.
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.
Hi All,
Here is the link to the roadmap for Mbed TLS and PSA Crypto in the coming quarters.
https://developer.trustedfirmware.org/w/mbed-tls/roadmap/
If you are interested in collaborating on any of the roadmap features or other features in the project, please let your interest known via. the mailing lists.
Note that the expected quarter when a feature will be completed is based on very rough estimates of the effort involved and therefore might change.
Roadmap will be reviewed and updated at the start of every quarter depending on progress made in previous quarter.
Thanks,
Shebu
(Mbed TLS, PSA Crypto Technology Manager, Arm)
Hi all,
As a general rule I'll start a thread of each of the changes to be discussed
for inclusion in Mbed TLS 3.0, but as an exception to that rule, I'm grouping
several items here because I suspect they probably won't generate much
discussion (if any).
Note: in general we keep obsolete crypto primitives in the code base (disabled
by default at compile time), so that people can still use them to process old
data at rest. This list however is about TLS options, i. e. handling live
data in transit, so it makes sense to completely remove them from the code
base once they're not used any more. It also decreases the complexity of the
code base, hence improving its maintainability, testability and security.
* Drop support for parsing SSLv2 ClientHello
(`MBEDTLS_SSL_SRV_SUPPORT_SSLV2_CLIENT_HELLO`). This was only needed back when
common frameworks (old version of Java most motably) used this format for
ClientHellos for compatibility with old an buggy servers, and when people
would actually consider negociating SSL 2.0. Fortunately, that's not the case
any more. Also, removing this unblocks some much-needed refactorings and
simplification of the code (and this option has become hard to test).
* Drop support for SSLv3 (`MBEDTLS_SSL_PROTO_SSL3`). This version of the
protocol was deprecated by the IETF (MUST NOT use since 2015 - RFC 7568) and
is no longer widely used.
* Drop support for compatibility with our own previous buggy implementation of
truncated HMAC (`MBEDTLS_SSL_TRUNCATED_HMAC_COMPAT`). This is only useful for
people who want to interoperate with buggy pre-2.7 Mbed TLS. Since those
versions are no longer maintained, hopefully everyone has updated by now.
* Drop support for TLS record-level compression (`MBEDTLS_ZLIB_SUPPORT`).
There are potential security issues with this option (compression if any
should be done at the appplication level in order to separate secrets from
attacker-controlled content), it's not widely used,
and was removed in TLS 1.3.
* Drop RC4 ciphersuites. These have been prohibited by RFC 7465 since 2015.
(Note: as a bonus, we can then remove the config.h option
`MBEDTLS_REMOVE_ARC4_CIPHERSUITES` as well.)
* Drop the single-DES ciphersuites. 56-bit keys, need I say more?
* Support for SSL record hardware acceleration
(`MBEDTLS_SSL_HW_RECORD_ACCEL`). Nobody in the team knows how it's supposed
to work, it's entirely untested, and we think nobody uses it, it's been failing to
build for a while and nobody complained so far. (Note: we still fixed the bug,
see PR #2262.)
Do you agree with the above list? Are you (or people you know) using one of
those features? Would you add things to that list (keeping the focus on
SSL/TLS obsolete features for now)?
Thanks in advance for sharing your thoughts!
Regards,
Manuel.
Hi again,
Note: I've created a wiki page [1] to summarize and consolidate the results of
the discussions that will be happening here about Mbed TLS 3.0.
[1]: https://developer.trustedfirmware.org/w/mbed-tls/tech-plans-3.0/
I also wanted to note that the current goals, as announced yesterday, contain
some changes compared to what had been announced nearly one year ago [2], so
I'd like to briefly recap what changed and what didn't.
[2]: https://tls.mbed.org/tech-updates/blog/working-towards-mbed-tls-3
Preparing a future based on PSA Crypto
--------------------------------------
We remain committed to that, but are now taking a different route towards that
goal. Initially we started to split Mbed Crypto out of Mbed TLS, which was not
the clean split between PSA Crypto and TLS/X.509 than we want in the long run,
so the plan was to evolve towards that. With the experience gained, we now
think it's easier to evolve things in one place, so we merged back mbed-crypto
into the mbedtls repo (see [3]), and still plan on making PSA Crypto its own
product, but only when we're ready to make that split cleanly.
[3]: https://github.com/ARMmbed/mbedtls/issues/3064
Also, we initially hinted that the long-standing `mbedtls_` crypto APIs would
be removed in Mbed TLS 3.0 (superseded by the PSA Crypto APIs). We're now
considering a more gradual and hopefully more realistic transition where Mbed
TLS 3.0 continues to offer some of those APIs for compatibility with existing
code-bases, and they would only be actually removed in Mbed TLS 4.0.
TLS 1.3 and message processing rework
-------------------------------------
This is still not part of a realistic roadmap for Mbed TLS 3.0, but still
close to our hearts for the future.
Switching to a new licensing and contribution model
---------------------------------------------------
This has been done already. The development branch now uses Apache 2.0 only,
while the LTS branches are still dual-licensed Apache/GPL2. We moved away from
a CLA and closer to an inbound == outbound model (not quite == yet because of
the differences between development and LTS branches), see [4].
[4]: https://github.com/ARMmbed/mbedtls/issues/3054
Opening up the governance of the project
----------------------------------------
This also happened already. Mbed TLS is now under open governance as part of
the trustedfirmware.org structure.
As a consequence of this move, Mbed TLS is now more focused on building and
maintaining a healthy community of users, contributors and maintainers.
Again, I hope that was clear and feel free to ask if you have any question or
remark. I'll follow up by starting threads on more specific items.
Regards,
Manuel.
Hi all,
In the next few months we'll be preparing version 3.0 of Mbed TLS (with a goal
of releasing in the 3rd quarter of calendar year 2020, see our roadmap [1]).
[1]: https://developer.trustedfirmware.org/w/mbed-tls/roadmap/
We've been maintaining full API compatibility since Mbed TLS 2.0.0 was
released in July of 2015, so this will be our first chance in 5 years to clean
up any API that we've found not to be entirely satisfactory, or no longer
needed.
This is the first in a series of threads discussing what we would like to do
in Mbed TLS 3.0 and how (or what we should rather postpone or not do at all).
It will present the high-level goals and list some items as examples. Specific
items that deserve further discussion (either to decide whether to include
them in 3.0, or refine their scope or meaning) will be discussed each in
their own thread.
Clean up the code by removing old things
----------------------------------------
This facilitates maintenance and testing.
Examples:
- Remove support for SSL 3.0 and other deprecated protocol options. (But keep
support for old crypto that could be useful for data at rest.)
- Remove API functions that have been superseded.
Improve existing APIs, behaviours, and defaults
-----------------------------------------------
This is mainly small things we just couldn't do in the 2.x line due to our
compatibility rules.
Examples:
- Upgrade the default TLS config to only offer (D)TLS 1.2 with forward-secure
key exchanges and AEAD ciphers.
- Add the 'const' qualifier to various arguments of existing APIs.
- Add size arguments to existing APIs that lack such arguments.
Reduce the surface of the public API
------------------------------------
This makes it easier to evolve the library while maintaining API
compatibility, and also makes testing easier.
Examples:
- Forbid direct access to members of most (all?) structures.
- Define more clearly which APIs are internal and forbid access to them.
- Move some non-core modules that are only useful for examples out of the
library (for example, certs.s).
Prepare the migration to PSA Crypto
-----------------------------------
Currently Mbed TLS consists of three libraries: SSL/(D)TLS, X.509, and Crypto.
Furthermore, currently Crypto provides both the long-standing `mbedtls_` APIs
and the new PSA Crypto APIs, and the TLS and X.509 libraries still largely
rely on the `mbedtls_` APIs, as does probably a large amount of external code.
Ultimately, we want to move to place where TLS and X.509 only rely on the PSA
Crypto API (whose reference implementation will be independent and longer part
of Mbed TLS), and where nobody uses the legacy `mbedtls_` APIs any more. But
that's a goal for Mbed TLS 4.0. In the meantime, Mbed TLS 3.0 should pave the
way for this.
The most important thing we want to do in 3.0 is to make most of the low-level
crypto modules internal, and only keep the high-level crypto modules to ease
the migration for existing users of the `mbedtls_` crypto APIs. Concretely,
this would mean for example that the `mbedtls_aes_` functions and types would
no longer be part of the API, but using AES via the `mbedtls_cipher_` APIs
would still be supported for existing users until Mbed TLS 4.0 - and of course
using AES via the PSA Crypto API is the way forward.
As this is a vast and complex topic, there will be a specific thread on where
exactly we can and would like to draw the line of which crypto APIs are
becoming private in Mbed TLS 3.0 and which are maintained until Mbed TLS 4.0
to ease migration.
Note: this strongly overlaps with the previous section (reduce the surface of the
public API), but the two are still distinct as they're guided by different
incentives: general maintainability vs supporting a specific migration.
I hope this email starts to clarify what Mbed TLS 3.0 should look like. Feel
free to ask questions if anything's not clear, and again, there will be
follow-up threads in the coming days and week to discuss specific aspects in
more details.
Best regards,
Manuel (Mbed TLS developer)