mirror of
https://github.com/yuzu-emu/mbedtls.git
synced 2024-11-27 02:54:14 +01:00
aabbb582eb
This commit is the first in a series demonstrating how code-size can be reduced by hardcoding parts of the SSL configuration at compile-time, focusing on the example of the configuration of the ExtendedMasterSecret extension. The flexibility of an SSL configuration defined a runtime vs. compile-time is necessary for the use of Mbed TLS as a dynamically linked library, but is undesirable in constrained environments because it introduces the following overhead: - Definition of SSL configuration API (code-size overhead) (and on the application-side: The API needs to be called) - Additional fields in the SSL configuration (RAM overhead, and potentially code-size overhead if structures grow beyond immediate-offset bounds). - Dereferencing is needed to obtain configuration settings. - Code contains branches and potentially additional structure fields to distinguish between different configurations. Considering the example of the ExtendedMasterSecret extension, this instantiates as follows: - mbedtls_ssl_conf_extended_master_secret() and mbedtls_ssl_conf_extended_master_secret_enforced() are introduced to configure the ExtendedMasterSecret extension. - mbedtls_ssl_config contains bitflags `extended_ms` and `enforce_extended_master_secret` reflecting the runtime configuration of the ExtendedMasterSecret extension. - Whenever we need to access these fields, we need a chain of dereferences `ssl->conf->extended_ms`. - Determining whether Client/Server should write the ExtendedMasterSecret extension needs a branch depending on `extended_ms`, and the state of the ExtendedMasterSecret negotiation needs to be stored in a new handshake-local variable mbedtls_ssl_handshake_params::extended_ms. Finally (that's the point of ExtendedMasterSecret) key derivation depends on this handshake-local state of ExtendedMasterSecret. All this is unnecessary if it is known at compile-time that the ExtendedMasterSecret extension is used and enforced: - No API calls are necessary because the configuration is fixed at compile-time. - No SSL config fields are necessary because there are corresponding compile-time constants instead. - Accordingly, no dereferences for field accesses are necessary, and these accesses can instead be replaced by the corresponding compile-time constants. - Branches can be eliminated at compile-time because the compiler knows the configuration. Also, specifically for the ExtendedMasterSecret extension, the field `extended_ms` in the handshake structure is unnecessary, because we can fail immediately during the Hello- stage of the handshake if the ExtendedMasterSecret extension is not negotiated; accordingly, the non-ExtendedMS code-path can be eliminated from the key derivation logic. A way needs to be found to allow fixing parts of the SSL configuration at compile-time which removes this overhead in case it is used, while at the same time maintaining readability and backwards compatibility. This commit proposes the following approach: From the user perspective, for aspect of the SSL configuration mbedtls_ssl_config that should be configurable at compile-time, introduce a compile-time option MBEDTLS_SSL_CONF_FIELD_NAME. If this option is not defined, the field is kept and configurable at runtime as usual. If the option is defined, the field is logically forced to the value of the option at compile time. Internally, read-access to fields in the SSL configuration which are configurable at compile-time gets replaced by new `static inline` getter functions which evaluate to the corresponding field access or to the constant MBEDTLS_SSL_CONF_FIELD_NAME, depending on whether the latter is defined or not. Write-access to fields which are configurable at compile-time needs to be removed: Specifically, the corresponding API itself either needs to be removed or replaced by a stub function without effect. This commit takes the latter approach, which has the benefit of not requiring any change on the example applications, but introducing the risk of mismatching API calls and compile-time configuration, in case a user doesn't correctly keep track of which parts of the configuration have been fixed at compile-time, and which haven't. Write-access for the purpose of setting defaults is simply omitted. |
||
|---|---|---|
| .. | ||
| baremetal_test.h | ||
| baremetal.h | ||
| config-ccm-psk-tls1_2.h | ||
| config-mini-tls1_1.h | ||
| config-no-entropy.h | ||
| config-suite-b.h | ||
| config-thread.h | ||
| README.txt | ||
This directory contains example configuration files.
The examples are generally focused on a particular usage case (eg, support for
a restricted number of ciphersuites) and aim at minimizing resource usage for
this target. They can be used as a basis for custom configurations.
These files are complete replacements for the default config.h. To use one of
them, you can pick one of the following methods:
1. Replace the default file include/mbedtls/config.h with the chosen one.
(Depending on your compiler, you may need to adjust the line with
#include "mbedtls/check_config.h" then.)
2. Define MBEDTLS_CONFIG_FILE and adjust the include path accordingly.
For example, using make:
CFLAGS="-I$PWD/configs -DMBEDTLS_CONFIG_FILE='<foo.h>'" make
Or, using cmake:
find . -iname '*cmake*' -not -name CMakeLists.txt -exec rm -rf {} +
CFLAGS="-I$PWD/configs -DMBEDTLS_CONFIG_FILE='<foo.h>'" cmake .
make
Note that the second method also works if you want to keep your custom
configuration file outside the mbed TLS tree.