Configuration Fetch Functions

Configuration data, such as certificates, API keys, authentication tokens, and encryption keys, is stored securely in the Microvisor cloud as key-value pairs on a per-account basis. You define each key's name when you upload its value. This is done using the Microvisor API.

Configuration data is scoped: either to all of the devices associated with a Twilio account, or to a single device under that account. Use the former scope for data common to all devices: for example, an API key for a cloud service which all of them post data to or request data from. The device-level scope might be used for information unique to an individual device's use-case.

The Microvisor cloud maintains two types of configuration data: 'secrets' and 'configs', stored as key-value pairs. Configs are items that are not confidential and so may be both created and subsequently read back using the Microvisor REST API. An example might be the base of a device's publicly readable application name and version string.

Secrets, however, are not viewable via API access once they have created. Their values will always remain hidden.

These levels of visibility only govern API access to the data — devices' application firmware can read both types of data. Nonetheless, when devices request a key's value, they must indicate the data type in their request configuration.

For more information on the API's account-level Config and Secret resources, and device-level Config and Secret subresources, please see the Microvisor API documentation.

Requests issued to Microvisor return immediately with a success or failure indication. However, success does not mean that the requested configuration data has been retrieved. The retrieval process is asynchronous and is signaled via the notification center you created and associated with your Config Fetch data channel. Microvisor posts a notification of type MV_EVENTTYPE_CHANNELDATAREADABLE and triggers an interrupt when data is received from the channel. Your interrupt service routine should set a flag, which your main code can read and proceed to get the received data: in this case the Config Fetch response. This can be parsed to check that the data request was successful and, if so, your code can proceed to access the configuration data value it contains.

All of the functions described below return a 32-bit integer that is one of the values from the standard Microvisor enumeration MvStatus. All possible error values for a given system call are provided with each function's description.

Success is always signaled by a return value of zero (MV_STATUS_OKAY).

Request configuration data via a network channel

This call, if successful, may subsequently yield any of the following notifications.

Use this call to access configuration data that you have already uploaded to secure storage in the Microvisor cloud. Secrets can be uploaded using the Microvisor API.

The application makes use of channels of type MV_CHANNELTYPE_CONFIGFETCH to make requests for configuration data. The channel must be open for the request to be issued and of the correct type.

For each channel, only one request can be issued. If Microvisor returns MV_STATUS_PARAMETERFAULT, MV_STATUS_INVALIDHANDLE, MV_STATUS_INVALIDBUFFERSIZE or MV_STATUS_CHANNELCLOSED, then the request will not have been issued, and you can reconfigure the request and try again. Any other value indicates that the request has been sent, and any attempt to issue it again, or to use the channel for a fresh request, will result in MV_STATUS_REQUESTALREADYSENT being returned. Instead, send any subsequent configuration data request through a new channel. You can re-use the channel definition structure and buffers if you wish. Be sure to close the channel used for a given request once you have received the response or a failure notification.

The call's request parameter takes a pointer to an MvConfigKeyFetchParams structure:

1
struct MvConfigKeyFetchParams {
2
  uint32_t num_items,
3
  struct MvConfigKeyToFetch *keys_to_fetch
4
}

This structure's properties are:

• num_items — The number of items of configuration data you are requesting.
• keys_to_fetch — An array of MvConfigKeyToFetch structures, each of which identifies a single item of configuration data to retrieve.

The MvConfigKeyToFetch structure is defined as:

1
struct MvConfigKeyToFetch {
2
  enum MvConfigKeyFetchScope scope,
3
  enum MvConfigKeyFetchStore store,
4
  struct MvSizedString *key
5
}

The integer placed in scope will be one of the following values:

The integer placed in store will be one of the following values:

The value of key is a data structure that provides the name of the requested item. You set a key's name when you upload its value.

This section of a C function shows the usage of mvSendConfigFetchRequest(). Further sections will be shown in the System Calls below.

1
/**
2
 * @brief Request the value of a secret.
3
 *
4
 * @param value_buffer - Whether the value will be written back to.
5
 * @param key          - The key name we're targeting.
6
 *
7
 * @returns `true` if the value was retrieved successfully,
8
 *          otherwise `false`
9
 */
10
bool config_get_secret(char *value, char key[]) {
11

12
  // Set up the request parameters
13
  struct MvConfigKeyToFetch key_one = {
14
    .scope = MV_CONFIGKEYFETCHSCOPE_ACCOUNT,    // An account-level value
15
    .store = MV_CONFIGKEYFETCHSTORE_SECRET,     // A secret value
16
    .key = {
17
            .data = (uint8_t*)key,
18
            .length = strlen(key)
19
    }
20
  };
21

22
  uint32_t item_count = 1;
23
  struct MvConfigKeyToFetch keys[item_count];
24
  keys[0] = key_one;
25

26
  struct MvConfigKeyFetchParams request = {
27
    .num_items = item_count,
28
    .keys_to_fetch = keys
29
  };
30

31
  // Request the value of the key specified above
32
  server_log("Requesting value for key '%s'", key);
33
  enum MvStatus status = mvSendConfigFetchRequest(config_handles.channel, &request);
34
  if (status != MV_STATUS_OKAY) {
35
    // Failure -- report and close channel
36
    server_error("Could not issue config fetch request");
37
    config_close_channel();
38
    return false;
39
  }
40

41
  // Wait for the data to arrive
42
  received_config = false;
43
  uint32_t last_tick = HAL_GetTick();
44
  while(HAL_GetTick() - last_tick < CONFIG_WAIT_PERIOD_MS) {
45
    if (received_config) break;
46
  }
47

48
  if (!received_config) {
49
    server_error("Config fetch request timed out");
50
    config_close_channel();
51
    return false;
52
  }
53

54
  ...
55
}

Access the response to a request for configuration data

Your application should call mvReadConfigFetchResponseData() when the channel receives a notification of type MV_EVENTTYPE_CHANNELDATAREADABLE. Microvisor will write an MvConfigResponseData record which your code can then parse:

1
struct MvConfigResponseData {
2
  enum MvConfigFetchResult result,
3
  uint32_t num_items
4
}

The integer placed in result will be one of the following values:

If the operation was successful, your code can call mvReadConfigResponseItem() for each returned item. The number of items available is given by num_items. The order of the returned items matches the order of items in the source request.

This example continues the function begun in mvSendConfigFetchRequest().

1
bool config_get_secret(char *value_buffer, char key[]) {
2
  ...
3

4
  // Parse the received data record
5
  server_log("Received value for key '%s'", key);
6
  struct MvConfigResponseData response = {
7
    .result = 0,
8
    .num_items = 0
9
  };
10

11
  status = mvReadConfigFetchResponseData(config_handles.channel, &response);
12
  if (status != MV_STATUS_OKAY || response.result != MV_CONFIGFETCHRESULT_OK || response.num_items != item_count) {
13
    server_error("Could not get config item (status: %i; result: %i)", status, response.result);
14
    config_close_channel();
15
    return false;
16
  }
17

18
  ...
19
}

Access requested configuration data

To retrieve the value of a specific key that you have successfully retrieved, call mvReadConfigResponseItem() and pass in an MvConfigResponseReadItemParams structure to indicate which item you require and where Microvisor should write it:

1
struct MvConfigResponseReadItemParams {
2
  enum MvConfigKeyFetchResult *result,
3
  uint32_t item_index,
4
  struct MvSizedString *buf
5
}

The integer placed in the memory referenced by result will be one of the following values:

The structure's other properties are:

• item_index — The index of the item you want. The order of the returned items matches the item request order.
• buf — A pointer to a buffer structure which Microvisor will use to write back the requested item.

This example continues the function begun in mvSendConfigFetchRequest().

1
bool config_get_secret(char *value_buffer, char key[]) {
2
  ...
3

4
  uint8_t  value[65] = {0};
5
  uint32_t value_length = 0;
6
  enum MvConfigKeyFetchResult result = 0;
7

8
  struct MvConfigResponseReadItemParams item = {
9
    .result = &result,
10
    .item_index = 0,
11
    .buf = {
12
      .data = &value[0],
13
      .size = 64,
14
      .length = &value_length
15
    }
16
  };
17

18
  // Get the value itself
19
  status = mvReadConfigResponseItem(config_handles.channel, &item);
20
  if (status != MV_STATUS_OKAY || result != MV_CONFIGKEYFETCHRESULT_OK) {
21
    server_error("Could not get config item (status: %i; result: %i)", status, result);
22
    config_close_channel();
23
    return false;
24
  }
25

26
  // Copy the value data to the requested location
27
  strncpy(value, (char*)value, value_length + 1);
28
  config_close_channel();
29
  return true;
30
}