"Move crypto-specific code from library/Makefile to a new file" accidentally
copied two lines instead of moving them. Remove the copy that's now in
`crypto-library.make`, since the variables are defined earlier in
`crypto-common.make`. The variables aren't actually used in
`crypto-common.make`, but they could be (arguably should be used to
define `TF_PSA_CRYPTO_LIBRARY_PRIVATE_INCLUDE`).
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Fix a bug whereby `crypto-common.make` was appending to `LOCAL_LDFLAGS`
before `common.make` set the initial value. This broke the build with
pthread enabled: `THREADING` was correctly getting autodetected, but the
addition of `-lpthread` to `LOCAL_LDFLAGS` didn't work.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
The new file is in Mbed TLS for now. Once we have finished moving code to
it, it will move to TF-PSA-Crypto.
What got moved:
* List of generated .data files in crypto
* Rules to generate .data files in crypto
* List of test suites in crypto
* List of generated .h files in crypto
* Rules to generate .h in crypto
What didn't get moved:
* Rules to generate the crypto part of `$(GENERATED_CONFIG_DATA_FILES)`,
because they are currently mixed with the rule for the mbedtls part. This
will be done in a subsequent commit.
* Rules to generate .c files from .function files, and to compile the
resulting .c files. At least for now, we let Mbed TLS decide how to do
that on its own.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
The new file is in Mbed TLS for now. Once we have finished moving code to
it, it will move to TF-PSA-Crypto.
What got moved:
* List of generated .c files in crypto
* Rules to build generated .c files in crypto
* List of apps in crypto
* Rules to build apps in crypto
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
The new file is in Mbed TLS for now. Once we have finished moving code to
it, it will move to TF-PSA-Crypto.
What got moved:
* List of object files from crypto
* List of generated .c files in crypto
* Rules to build generated .c files in crypto
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Use separate variables for the crypto part of lists of generated C files,
generated objects, sample programs and test data files.
No behavior change.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Note that `THREADING` detection must be done after
`TF_PSA_CRYPTO_LIBRARY_PUBLIC_INCLUDE` is defined. Otherwise it won't detect
whether pthread is needed, and will never link with `-lpthread`.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
When running the preprocessor to determine whether pthread is enabled, only
use TF-PSA-Crypto include paths. Don't use the rest of `LOCAL_CFLAGS`,
including Mbed TLS include paths, which aren't really useful here.
This will simplify later refactorings, because it simplifies a dependency
chain [crypto paths] → `LOCAL_CFLAGS` → `THREADING` → `LOCAL_LDFLAGS`
into just [crypto paths] → `THREADING` → `LOCAL_LDFLAGS`.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Define variables that are meant to be possibly overridden on the make
command line (or in a parent makefile) at the top. In particular, define
them before including the crypto and framework makefiles, so these makefiles
can use the default values if there's no parent setting.
Also move some internal variables earlier or later, so that a subsequent
refactoring step can have things in the right order in the mbedtls
per-directory makefile:
1. Define variables consumed by the per-directory crypto makefile.
2. Include the per-directory crypto makefile.
3. Use variables defined by the per-directory crypto makefile.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Define these intermediate variables in the crypto helper file.
No behavior change except possibly an inconsequential reordering of compiler
options.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Currently, Mbed TLS can be built with make, and we rely on this in many
`all.sh` components. Mbed TLS knows how to build TF-PSA-Crypto, but this
changes from time to time, and it's hard to do the necessary changes in both
repositories at the same time.
Create a file that Mbed TLS can consume to find out some information needed
to build TF-PSA-Crypto, such as the locations of various files.
Create this file in Mbed TLS. Once we have finished moving code to it, the
file will move to TF-PSA-Crypto.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
We put that in 3.6.0 because we wanted to minimize changes in a minor
release, and in particular we wanted users to be able to build the library
if they were checking out a release tag without checking out submodules
recursively. That was possible because 3.6.x release tags contain the
generated files.
Since 4.0.0, it's completely impossible to build Mbed TLS without the
`tf-psa-crypto` submodule. So there's no point in trying to allow a build
without the `framework` submodule.
In the libtestdriver1 build, where we copy part of the framework, copy the
framework makefile as well, which is what we use to check for the presence
of the framework (even though the framework makefile doesn't do anything
useful after all).
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Don't print the differences: interested users can just run `git diff` (or
save the old file and run `comm`).
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Test that `scripts/data_files/config-options-current.txt` is up-to-date.
This file needs to change every time we add or remove a config option.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
This script may be generalized to check other files that need lists of
current options. But for now, the script just checks
`scripts/data_files/config-options-current.txt`.
This script is identical to the file in crypto. If the file grows to support
multiple targets, we'll probably want to split it, with a generic part in
the framework and a project-specific part (probably little more than the
list of targets) in each project. But for now the file is too simple to split.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
It doesn't matter how a macro was used in a previous minor version of the
library. What matters is current information about options and internal
symbols, and information about past versions from which a macro may have
been removed.
The output is mostly the same, but:
* Macros that were options in 3.6, became internal in 4.0 and have now
been completely removed are now shown as removed, not internal.
* Macros that were options in 3.6, were completely removed in 4.0, and are
now back but internal, are now shown as internal, not removed.
* Macros that were options in 3.6, were removed in 4.0 and are back to
being options are no longer rejected.
* Macros that were options in 3.6, were removed in 4.0 and are back to
being internal derived macros in TF-PSA-Crypto are no longer rejected.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
secp192 curves are no more supported in tf-psa-crypto and also all the
temporary fixes has been removed. This one can be removed as well.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
Even though the TLS RFCs do not mandate libraries to expose *Error
Alerts* (as defined in RFC8446 6.2 for TLS 1.3 and in RFC5246 7.2.2 for
TLS 1.2) to the user, there are use cases when it is handy to get the
actual last received fatal error instead of a generic one. For instance
this enables the user to differ between received fatal errors in case
`mbedtls_ssl_handshake()`, `mbedtls_ssl_handshake_step()` or
`mbedtls_ssl_read()` returned `MBEDTLS_ERR_SSL_FATAL_ALERT_MESSAGE`.
This changesets stores the last incoming fatal alert in
`mbedtls_ssl_context` and provides `mbedtls_ssl_get_alert()` as a getter
for retrieving it. Another option would be to provide a callback
mechanisms for all kinds of alerts (not only fatals) but for simplicity
I discarded this option.
Signed-off-by: Nico Geyso <ng@gsmk.de>
