Rename the generic name `ctx` of `mbedtls_platform_context`
in `platform_alt.c` to a specific name `plat_ctx`, to avoid conflicts
when used as external in crypto modules.
To avoid collisions between the psa `crypto_platform.h` file and the
platform specific `crypto_platform.h` file, for the init \ terminate
functions, rename the latter to `crypto_device_platform`.
The most common issue with using littlefs in mbed-os is when users
change from littlefs->FAT->littlefs (or with MBR or similar). When this
corrupts the superblock, littlefs tries to fall back to the backup
superblock. However, at this point in the time the old superblock may be
very out-of-date and pointing to an incorrect filesystem.
There's no complete solution to a malicious modification of the
filesystem (short of checking all metadata+data, a very expensive
operation), but we can at least expand our validation to all of the
metadata for the filesystem. This at least catches the common issues
with changing between different filesystems.
the own_oob and peer_oob flags were not being set to 1 even though
an OOB pairing request was in progress, which therefore prevented
OOB data from being passed down to the softdevice during a OOB
pairing operation, thus causing the OOB pairing process to fail.
The function in the Nordic SDK for generating OOB data,
sd_ble_gap_lesc_oob_data_get, requires local LE Secure Connection
P256 Public Keys in {X,Y} format, but was being supplied with
the local secret key. This caused the generated OOB data to
fail to correspond to the Public Keys, which caused a mismatch
during the OOB pairing phase of the OOB confirmation value by
a remote peer when attempting to verify the OOB data against
the Public Keys, ultimately causing the OOB pairing request to
fail with a Confirm Value Failed (0x04) error.
The GenericSecurityManager tracks the most recent OOB data generated
by the PAL and the PAL function to generate OOB data is expected to
be asynchronous such that the OOB data is returned via a callback.
There was a race condition on the security manager's oob data variable
because it was cleared (set to all zeros) after calling PAL generate.
The expectation was that the clear operation would occur before the
callback executed, but this is proving to not be the case. Instead,
the callback is being executed as if it were syncronous with PAL
generate, then PAL generate returns and the oob data is cleared,
thereby losing the generated oob data that was set in the callback.
To fix the issue, clear the oob data variables before calling into
the PAL.
Fix the following build warning found when building with
ARMC6 toolchain for NRF52_DK with mbed cli version 1.8.3
[Warning] thread_mle_message_handler.c@762,0: #188-D: enumerated type mixed with another type
[Warning] thread_mle_message_handler.c@834,0: #188-D: enumerated type mixed with another type
This commit makes the repo used to import new Mbed TLS versions into Mbed OS
a parameter, to allow CI scripts (and any other script or users) to specify
specific repos to use for testing.
Mel Weed
Kari Haapalehto
Seppo Takalo
Jarno Lamsa
Ari Parkkila
Cruz Monrreal
Ron Eldor
Yossi Levy
David Saada
paul-szczepanek-arm
offirko
Christopher Haster
Nic Costa
Naveen Kaje
Guy Wild
Fahim Alavi
Terence Zhang
Alexander Zilberkant
Leszek Rusinowicz
kegilbert
Mahesh Mahadevan
Simon Butcher