NVStore: deprecated implementation removed

Author: Veijo Pesonen

TESTS/configs/baremetal.json

@@ -32,8 +32,7 @@
         "events",
         "kv-global-api",
         "sd",
-        "qspif",
-        "nvstore"
+        "qspif"
     ],
     "target_overrides": {
         "*": {

TESTS/host_tests/trng_reset.py

@@ -17,7 +17,7 @@
 This script is the host script for trng test sequence, it send the 
 step signaling sequence and receive and transmit data to the device after 
 reset if necesarry (default loading and storing mechanism while reseting the device
-is NVstore, in case NVstore isn't enabled we'll use current infrastructure,
+is KVStore, in case KVStore isn't enabled we'll use current infrastructure,
 for more details see main.cpp file)
 """
 
@@ -142,4 +142,4 @@ def test_steps(self):
         self.send_kv(MSG_KEY_EXIT, MSG_VALUE_DUMMY)
 
         # The sequence is correct -- test passed.
-        yield
+        yield

TESTS/integration/COMMON/sample.txt

@@ -267,7 +267,6 @@ The [storage APIs](storage.html) include file system APIs, for file system opera
 <td><a href="littlefilesystem.html">LittleFileSystem</a></td>
 <td><a href="chainingblockdevice.html">ChainingBlockDevice</a></td>
 <td><a href="../apis/dataflashblockdevice.html">DataFlashBlockDevice</a></td>
-<td><a href="nvstore.html">NVStore</a></td>
 </tr>
 <tr>
 <td><a href="static-global-api.html">Static Global API</a></td>
@@ -3115,4 +3114,4 @@ An application can extend capabilities of `SimpleMessageParser` by adding new re
 
 - [MessageParser](messageparser.html) API reference.
 - [MessageBuilder](messagebuilder.html) API reference.
-- [NFC architecture](../reference/nfc-technology.html).
+- [NFC architecture](../reference/nfc-technology.html).

UNITTESTS/empty_baseline/unittest.cmake

@@ -31,7 +31,6 @@ set(unittest-sources
 	../features/storage/kvstore/conf/kv_config.cpp
 	../features/storage/kvstore/filesystemstore/FileSystemStore.cpp
 	../features/storage/system_storage/SystemStorage.cpp
-	../features/storage/nvstore/source/nvstore.cpp
 	../features/storage/blockdevice/ChainingBlockDevice.cpp
 	../features/storage/blockdevice/ReadOnlyBlockDevice.cpp
 	../features/storage/blockdevice/SlicingBlockDevice.cpp

components/TARGET_PSA/TARGET_TFM/COMPONENT_SPE/mbed_lib.json

@@ -1,6 +1,6 @@
 {
     "name": "tfm-s",
-    "macros": ["MBED_FAULT_HANDLER_DISABLED", "BYPASS_NVSTORE_CHECK=1"],
+    "macros": ["MBED_FAULT_HANDLER_DISABLED"],
     "config": {
         "max_ns_thread_count": {
             "help": "maximum allowed number of non-secure threads",

docs/design-documents/features/storage/BlockDevices/get_type_method.md

@@ -20,8 +20,6 @@ Below there is a list of some examples to explain the motivation and the need fo
 examples:
 - TDBStore needs to know if there are flash characteristics for the block device and if there aren�t it should use
   FlashSimBlockDevice to simulate a flash BlockDevice.
-- TDBStore should not co-exists with NVStore, but this is true only if TDBStore is running on internal memory. Therefore if TDBStore running on 
-  internal memory and NVStore is also there an error should be raised. 
 - When creating a file system you would prefer working with FAT on top of SD while LITTLEFS on top of any flash block device. 
   Those preference in favor of better performance.
 

features/device_key/README.md

@@ -1,31 +1,31 @@
 ## DeviceKey
 
-DeviceKey is a mechanism that implements key derivation from a root of trust key. The DeviceKey mechanism generates symmetric keys that security features need. You can use these keys for encryption, authentication and more. The DeviceKey API allows key derivation without exposing the actual root of trust, to reduce the possibility of accidental exposure of the root of trust outside the device.
+DeviceKey is a mechanism that implements key derivation from a Root of Trust(RoT) key. The DeviceKey mechanism generates symmetric keys that security features need. You can use these keys for encryption, authentication and more. The DeviceKey API allows key derivation without exposing the actual RoT, to reduce the possibility of accidental exposure of the RoT outside the device.
 
 We have implemented DeviceKey according to NIST SP 800-108, section "KDF in Counter Mode", with AES-CMAC as the pseudorandom function.
 
 ### Root of Trust
 
-The root of trust key, which DeviceKey uses to derive additional keys, is generated using the hardware random generator if it exists, or using a key injected to the device in the production process.
+The RoT key, which DeviceKey uses to derive additional keys, is generated using the hardware random generator if it exists, or using a key injected to the device in the production process.
 
-The characteristics required by this root of trust are:
+The characteristics required by this RoT are:
 
 - It must be unique per device.
 - It must be difficult to guess.
 - It must be at least 128 bits.
 - It must be kept secret.
 
-The DeviceKey feature keeps the root of trust key in internal storage, using the NVStore component. Internal storage provides protection from external physical attacks to the device.
+The DeviceKey feature keeps the RoT key in internal storage, using the KVStore component. Internal storage provides protection from external physical attacks to the device.
 
-The root of trust is generated at the first use of DeviceKey if the true random number generator is available in the device. If no true random number generator is available, you must pass the injected root of trust key to the DeviceKey before you call the key derivation API.
+The RoT is generated at the first use of DeviceKey if the True Random Number Generator(TRNG) is available in the device. If no TRNG is available, you must pass the injected RoT key to the DeviceKey before you call the key derivation API.
 
 ### Key derivation API
 
 `generate_derived_key`: This API generates a new key based on a string (salt) the caller provides. The same key is generated for the same salt. Generated keys can be 128 or 256 bits in length.
 
 #### Root of Trust Injection API
 
-`device_inject_root_of_trust`: You must call this API once in the lifecycle of the device, before any call to key derivation, if the device does not support True Random Number Generator (`DEVICE_TRNG` is not defined).
+`device_inject_root_of_trust`: You must call this API once in the lifecycle of the device, before any call to key derivation, if the device does not support TRNG (`DEVICE_TRNG` is not defined).
 
 #### Using DeviceKey 
 

features/storage/kvstore/tdbstore/TDBStore.cpp

@@ -24,10 +24,6 @@
 #include "mbed_error.h"
 #include "mbed_wait_api.h"
 #include "MbedCRC.h"
-//Bypass the check of NVStore co existance if compiled for TARGET_TFM
-#if !(BYPASS_NVSTORE_CHECK)
-#include "features/storage/system_storage/SystemStorage.h"
-#endif
 
 using namespace mbed;
 
@@ -1016,18 +1012,6 @@ int TDBStore::init()
         goto end;
     }
 
-//Bypass the check of NVStore co existance if compiled for TARGET_TFM
-#if !(BYPASS_NVSTORE_CHECK)
-
-    //Check if we are on internal memory && try to set the internal memory for TDBStore use.
-    if (strcmp(_bd->get_type(), "FLASHIAP") == 0 &&
-            avoid_conflict_nvstore_tdbstore(TDBSTORE) == MBED_ERROR_ALREADY_INITIALIZED) {
-
-        MBED_ERROR(MBED_ERROR_ALREADY_INITIALIZED, "TDBStore in internal memory can not be initialize when NVStore is in use");
-    }
-
-#endif
-
     _max_keys = initial_max_keys;
 
     ram_table = new ram_table_entry_t[_max_keys];