mbedlts: add as alternative to openssl#426
Conversation
XXX: make the meson options mutually exclusive, rebase onto other MRs In a recent conversation improving the depmod runtime, we noticed that kmod_module_signature_info() normally takes 20-25% of the total runtime for uncompressed. The related attempts at using threads, also indicated that OpenSSL may not be thread-safe... At least, not the way we use it. Enter Mbed TLS (formerly known as polarssl), self described as: Mbed TLS is a C library that implements X.509 certificate manipulation ... ... Its small code footprint makes it suitable for embedded systems. ... There are 3 major versions, all of which are supported AFAICT: - 2 circa 2015 - available in Debian 12/oldstable (+earlier) and Ubuntu 24.04 (+ earlier) - 3 circa 2021 - available in Debian 13+, Ubuntu 25.04+ and everywhere* - 4 Oct 2025 - very minimal distribution adoption In practical terms, using MbedTLS has proven to be a much shorter and simpler implementation. Where the ~20% time spent in kmod_module_signature_info() was reduced to practically zero. With the overall execution time dropping respectively - 0.43s -> 0.35s. Another way to look at it: - ~50k fewer instructions are executed, per module - ~55 fewer memory allocations are made, per module - ~2KB less memory is allocated, per module Also, Helgrind seems quite happy. There are some down sides through - ignoring the Ubuntu 25.04+ only availability. - MD4 support was removed with v3.0 - SM3 support is not available - neither in v3 nor v4 - there is no algo to string API, so we need a local mapping Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
|
The CI failures are normal/expected - the meson checks are foobard (as the XXX says) plus we need mbedtls in the containers. The "other MRs" mentioned are: |
|
Assuming the If that sounds reasonable, I would be in favior of first trying mbedtls and then falling back to openssl. |
| #------------------------------------------------------------------------------- | ||
|
|
||
| opt = 'mbedtls' | ||
| dep = dependency('mbedx509', version : '> 3.0.0', required : true) # XXX: make it an option |
There was a problem hiding this comment.
do you know if it also works with >= 4? I'm looking at https://repology.org/project/mbedtls/badges and I see 3.6.5 as "generally available", but I also don't want to lock ourselves in an old version. Also I see this note in https://pkgsrc.se/security/mbedtls4:
This contains major version 4 of the library, which is not backwards
compatible to version 2 or 3.
First time hearing of this library, so would like more information before adding it. For parsing the pkcs7 I wonder what the alternatives we have. Maybe ell would also work?
There was a problem hiding this comment.
Yes, some changes may be needed for v4, but I haven't checked exactly - mbedtls v4 isn't in Arch yet. I do expect them to be minimal though.
Instead of rehashing the wiki page or the website feel free to check them out. First time I heard about it was while looking at the dolphin emulator and the second time when OpenWrt switched to it by default...
A couple of notable points from the latter:
- considerably smaller
- LTS branch and stable ABI
Glancing at ell - it does have some PKCS8 handling, but it doesn't not seem to be exposed at the API level.
I am quite concerned about the community size, reviews, direct pushes to master, no CI, etc... Even though I am a big fan of its clean and well structured code base + extensive test coverage.
Edit: If possible, I would rather keep ell exploration as a follow-up, when most of the adjacent patches have landed or been rejected.
There was a problem hiding this comment.
ok... mbedtls seems to be more well known and used than I thought. I don't really buy this major version nonsense though. Piling up the list of cons:
- Ubuntu 25.04+ only availability... for v3. v4 not available anywhere.
- MD4 support was removed with v3.0
- SM3 support is not available - neither in v3 nor v4
- there is no algo to string API, so we need a local mapping
- will probably need changes to support v4
If that sounds reasonable, I would be in favior of first trying mbedtls and then falling back to openssl.
I will take another look at the PR, but I'm not happy of favoring mbedtls right now. IMO a config-time switch would be appropriate, at least for the next kmod version.
There was a problem hiding this comment.
ok, let's get this in.
- Can you rebase and remove the "Draft"?
- Can we have one config in CI added with mbedtls?
2 participants
XXX: make the meson options mutually exclusive, rebase onto other MRs
In a recent conversation improving the depmod runtime, we noticed that kmod_module_signature_info() normally takes 20-25% of the total runtime for uncompressed.
The related attempts at using threads, also indicated that OpenSSL may not be thread-safe... At least, not the way we use it.
Enter Mbed TLS (formerly known as polarssl), self described as:
Mbed TLS is a C library that implements X.509 certificate manipulation ... ... Its small code footprint makes it suitable for embedded systems. ...
There are 3 major versions, all of which are supported AFAICT:
In practical terms, using MbedTLS has proven to be a much shorter and simpler implementation. Where the ~20% time spent in kmod_module_signature_info() was reduced to practically zero. With the overall execution time dropping respectively - 0.43s -> 0.35s.
Another way to look at it:
Also, Helgrind seems quite happy.
There are some down sides through - ignoring the Ubuntu 25.04+ only availability.