NVSEncryptedPartition held two XTS_CONTEXT members (mEctxt, mDctxt) for
encryption / decryption. Their AES round keys are derived from the NVS
encryption key (HMAC-derived or plaintext from nvs_keys partition) and
therefore are sensitive secrets.
The destructor was empty, so when the NVS encrypted partition object
was destroyed -- on nvs_flash_deinit_partition(), on initialization
errors, and on any other teardown path -- the XTS round keys were left
in DRAM until the freed object's memory happened to be overwritten by
a later allocation. A subsequent stack/heap leak primitive would
recover the AES key from those bytes.
Fix:
* Initialize both XTS contexts in the constructor so the destructor's
free path is always safe (previously xts_init was only called in
init(); destruction before init() would have run xts_free on an
uninitialized struct).
* Provide a real destructor that calls XTS_FUNC(xts_free) on both
contexts, which performs mbedtls_platform_zeroize / esp_aes_xts free
semantics on the underlying AES contexts.
- BDL provider can be enabled vor NVS in the menuconfig option NVS_BDL_STACK
- Hierarchy of Partition class tree was adjusted and all operations were documented
- Class Partition is now derived from intrusive_list_node and ExceptionlessAllocable
- Class NVSPartition implements only the dual support for esp_partition and BDL
- Class NVSEncryptedPartition implements only encryption related extensions
This fixes the issue where multiline strings and strings with delimiters inside the nvs input csv file were incorrectly parsed, and adds back the ability to add comment lines anywhere in the CSV file.
The issue stems from the move away from the python built in csv module to manual parsing, which was made after moving away from using the csv module to parse mfg data.
This reverts back to using the csv module for parsing and writing csv data in both mfg_gen and nvs_partition_gen, fixes the original issue in mfg_gen and improves code quality which makes the code more readable and maintainable.
Closes https://github.com/espressif/esp-idf/issues/7175
* partition api changed from spi_flash* API to
esp_partition* API and is abstracted as a C++
interface.
* The old nvs encryption is still possible
* changed default unit test app partition table
* Partitions coming from esp_partition API are
checked for generic flash encryption. If yes,
an error is returned since generic flash
encryption isn't compatible with nvs
encryption
* esp32, esp32s2 tests don't require nvs_flash
but mbedtls now
Closes IDF-1340
Closes IDF-858