Hi Raoul,
Do I understand correctly that the problem with Mbed TLS as it is now is
that you need MBEDTLS_HAVE_ASM enabled for AESNI and disabled for
bignum? Would you want even more granularity?
In principle, we could create a new compile-time option MBEDTLS_MPI_ASM,
defaulting to what it does now (enabled if MBEDTLS_HAVE_ASM if the
platform is one of the known ones) but overridable in either direction.
However I don't like it much because we're trying to cut down on
compilation options to reduce the maintenance burden: each compilation
option adds complexity which makes it harder to understand all
interactions between different parts of the library, and adds some
testing burden. Symmetric and asymmetric crypto are mostly decoupled, so
this one wouldn't be too bad, but it all adds up.
In the long term, I expect that the different cryptographic algorithms
will become more decoupled, with a possibility to treat each one as a
black box that could be implemented by a hardware driver, and with a
uniform mechanism to select drivers (or maybe they should be called
engines). The evolution of the crypto part of the library to PSA is
going in this direction. But we aren't there yet.
Sorry that I don't have a more satisfying answer here.
--
Gilles Peskine
Mbed TLS developer
On 31/03/2021 09:13, Raoul Strackx via mbed-tls wrote:
> Hi all,
>
> We have a product that requires very strong security measures. When
> compiling the mbedtls library, we face the following issue: Compiling C
> code with LVI-mitigations is often much faster than relying on automatic
> LVI mitigations on assembly code. The MPI functions are a good example
> where we wish to rely on C source code. For other functions, we need to
> rely on assembly code in order to mitigate other vulnerabilities (e.g.,
> we require AESNI assembly instructions over C implementations of AES).
> Currently there isn't an option to choose between C/assembly per function.
>
> What would be an acceptable solution for this?
>
> greetings,
>
> Raoul
>
>
>
Hello,
In a nutshell:
1. Must Mbed TLS support Python 3.4 to configure and test, or can 3.6 be
enough?
2. Must the supplied CMake scripts support 2.8.12.2, or can 3.5.2 be enough?
This thread is about minimum tool versions to configure, build and test
Mbed TLS (excluding TLS interoperability testing and some maintainer
scripts) on Linux and similar (Unix-like) platforms. (This is not about
the set of platforms where Mbed TLS will _run_, which is as close to
“anything with CHAR_BIT==8 and sizeof(size_t) >= 4” as we can make it.)
Our general guideline is that Mbed TLS should build out of the box on
supported versions of major desktop and server operating systems. In
practice, this has tended to mean supporting tool versions from
RHEL/CentOS, SLES and Ubuntu LTS releases (but not necessarily extended
security maintenance releases).
Last year
(https://lists.trustedfirmware.org/pipermail/mbed-tls/2020-April/thread.html)
we concluded that we should support the following minimum versions,
which will remain supported in the Mbed TLS 2.16 long-time support (LTS)
branch:
clang 3.8
cmake 2.8.12.2
gcc 4.4
make 3.81
python 3.4 (in 2.16: only to build the unit tests, not to configure)
Since then, RHEL 6 and Ubuntu 16.04 have reached their end of life, the
CentOS world has changed considerably. Looking at maintained platforms
after April 2021
(https://github.com/ARMmbed/mbedtls/issues/2896#issuecomment-603471273),
our current goal for the upcoming Mbed TLS 2.x LTS (last release before
3.0) is:
clang 6.0
cmake 2.8.12.2 (or 3.5.2? or 3.10.2?)
gcc 4.8
make 3.82
python 3.6 (or 3.4.10?)
Regarding Python: is there any demand for supporting Python versions
older than 3.6? Python 3 is required to fine-tune the library
configuration (it is not needed if you use the default config.h or a
handwritten one) and build the unit tests.
Regarding CMake: it is increasingly problematic for us to support CMake
2.8.12, which is only required for RHEL 7: other distributions under
consideration have at least CMake 3.5. There is an ongoing effort to
improve our CMake scripts to make it easier to integrate Mbed TLS into a
larger project, but it is difficult to preserve backward compatibility
with 2.8.12. Would it be acceptable to require CMake >= 3.5? CMake >=
3.10.2?
If you have any constraints that are not captured here or if you have an
opinion regarding Python and CMake versions, please let us know quickly.
--
Gilles Peskine
Mbed TLS developer
Hi all,
We have a product that requires very strong security measures. When
compiling the mbedtls library, we face the following issue: Compiling C
code with LVI-mitigations is often much faster than relying on automatic
LVI mitigations on assembly code. The MPI functions are a good example
where we wish to rely on C source code. For other functions, we need to
rely on assembly code in order to mitigate other vulnerabilities (e.g.,
we require AESNI assembly instructions over C implementations of AES).
Currently there isn't an option to choose between C/assembly per function.
What would be an acceptable solution for this?
greetings,
Raoul
