mbedlts: add as alternative to openssl#426
Conversation
|
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?
Codecov Report❌ Patch coverage is
... and 6 files with indirect coverage changes 🚀 New features to boost your workflow:
|
|
Changes, in random order:
|
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Move openssl-related function to a separate file so it's easier to isolate the dependency on each crypto library. This will allow multiple implementations to co-exist in the same build. As a nice side effect we fallback to the "dummy" implementation in the (very likely) case that the openssl one fails. Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
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 modules. 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/LTS versions in the wild, - v2 released in 2015 - Debian 12- and Ubuntu 24.04- - v3 released in 2021 - Debian 13+, Ubuntu 25.04+ and everywhere* - v4 released in 2025 - close to non-existing adoption In practical terms, using MbedTLS has proven to be a much shorter and simpler implementation. Effectively eliminating the time spent in kmod_module_signature_info() to practically zero. With the overall execution time dropping respectively - 0.43s -> 0.35s on my machine. From instructions/memory statistics POV, we have (per module): - ~50k fewer instructions - ~55 fewer memory allocations - ~2KB less memory is allocated Also, Helgrind seems quite happy. Availability aside, there are a few IMHO minor downsides: - MD4 support was removed with v3 - SM3 support is not available - neither in v3 nor v4 - No algo to string API I wasn't able to find any distribution/builds that use MD4 or SM3 so this aspect shouldn't be too critical. Whereas for the algo-to-string API - it's a trivial mapping, that we can (should?) copy from the kernel alongside the enum itself... But that's an exercise for another day - alongside fixing the no openssl/mbedtls code path. Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
As the mbedtls introduction commit says, mbedtls v3 is not available in Debian 12 and Ubuntu 22.04/24.04. Although to ensure we have sufficient build coverage, let's enable it everywhere else. While also adding a permutation where it's the only crypto implementation built-in. Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
|
Small update:
|
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> Link: #426 Signed-off-by: Lucas De Marchi <demarchi@kernel.org>
Move openssl-related function to a separate file so it's easier to isolate the dependency on each crypto library. This will allow multiple implementations to co-exist in the same build. As a nice side effect we fallback to the "dummy" implementation in the (very likely) case that the openssl one fails. Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> Link: #426 Signed-off-by: Lucas De Marchi <demarchi@kernel.org>
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 modules. 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/LTS versions in the wild, - v2 released in 2015 - Debian 12- and Ubuntu 24.04- - v3 released in 2021 - Debian 13+, Ubuntu 25.04+ and everywhere* - v4 released in 2025 - close to non-existing adoption In practical terms, using MbedTLS has proven to be a much shorter and simpler implementation. Effectively eliminating the time spent in kmod_module_signature_info() to practically zero. With the overall execution time dropping respectively - 0.43s -> 0.35s on my machine. From instructions/memory statistics POV, we have (per module): - ~50k fewer instructions - ~55 fewer memory allocations - ~2KB less memory is allocated Also, Helgrind seems quite happy. Availability aside, there are a few IMHO minor downsides: - MD4 support was removed with v3 - SM3 support is not available - neither in v3 nor v4 - No algo to string API I wasn't able to find any distribution/builds that use MD4 or SM3 so this aspect shouldn't be too critical. Whereas for the algo-to-string API - it's a trivial mapping, that we can (should?) copy from the kernel alongside the enum itself... But that's an exercise for another day - alongside fixing the no openssl/mbedtls code path. Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> Link: #426 Signed-off-by: Lucas De Marchi <demarchi@kernel.org>
As the mbedtls introduction commit says, mbedtls v3 is not available in Debian 12 and Ubuntu 22.04/24.04. Although to ensure we have sufficient build coverage, let's enable it everywhere else. While also adding a permutation where it's the only crypto implementation built-in. Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> Link: #426 Signed-off-by: Lucas De Marchi <demarchi@kernel.org>
|
Applied, thanks! |
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.