Each router card will have some device-specific information like a a serial number, MAC addresses, etc. Often for embedded devices such data is stored on an EPROM chip. The router card doesn't have such a chip though, so we have to incorporate it into the firmware provisioning.
Here are two approaches. I was originally thought of the second. However, the first seems better to me. It integrates better into our provisioning flow and better protects the data from accidental change.
The first puts the info in files on a special read-only partition mounted at /data/rom. This can partition can be written during TPM provisioning, well before the rest of the firmware is flash.
The second puts the config in files in /data. Sentinel values in the firmware image must be replaced with real values before burning to a router card.
Approach 1
Data
Put the info in files in a special read-only partition mount at at /data/rom (or maybe just /rom). Such files are easily consumed by other services on the card, but cannot be modified.
/data/rom/serial_number - serial number in one line
/data/rom/mac_address/self - the mac address that the card will present to the host
/data/rom/mac_address/wifi - the mac address that the WiFi chipset should use
Provisioning process
Write a program or script to create the "rom" partition image given the specific values for each file. (Perhaps by modifying the idea in approach 2).
When provisioning the TPM on the router card, write that image as the first partition on the flash
sam-ba ... -a sdmcc -c write:<image>:<offset>
This partition should probably go after the memory reserved for the actual firmware. Otherwise, it would be overwritten when the actual firmware is flashed. Note as well that the offset must be a page boundary.
Now the router card is provisioned with all its static values (keys in the TPM and serial number, MACs, etc in the flash parition).
Later, the actual firmware can be written to the rest of the flash.
There are some details to work out here, but I like that the static values can be provisioned early in the router cards life, well before the firmware. That will be helpful in development, where we are frequently changing firmwares but don't want to change the device's static values.
Approach 2
Data
Put the info in files in the /data partition. Such files are easily consumed by other services on the card and will persist across firmware updates.
/data/serial_number - serial number in one line
/data/mac_address - the mac address that the card will present to the host
/data/wifi/mac_address - the mac address that the WiFi chipset should use
Provisioning process
I propose building the firmware image with sentinel values in these files. Before writing the firmware to a router card, replace the sentinel values with the actual values.
For example, a Xaptum serial number is 14 digits long: XRW02518000020. So in the master image, /data/serial_number can contain @XAPTUMSERIAL@. Before writing the firmware to a device, create a copy and replace @XAPTUMSERIAL@ with the actual serial number.
The actual serial number will be read from a QR-code on the router card label during firmware provisioning.
MAC addresses are 17 digits in human-readable form: 01:23:45:67:89:AB. So the master image /data/mac_address could contain @MACADDRESS_MAIN@ and /data/wifi/mac_address could contain @MACADDRESS_WIFI@.
We will register an OUI (MAC address prefix) with the IEEE, allowing us to create MAC addresses. We'll need to figure out a process for managing that generation process.
It might be easier for development if the sentinel values were valid serial numbers, MAC addresses, etc. That would be an easy change.
Tasks
[x] Add the files with sentinel values to the data rootfs overlay.
[x] Write a script or program to do the substitution on the firmware image.
drbild
commented
5 years ago
Each router card will have some device-specific information like a a serial number, MAC addresses, etc. Often for embedded devices such data is stored on an EPROM chip. The router card doesn't have such a chip though, so we have to incorporate it into the firmware provisioning.
Here are two approaches. I was originally thought of the second. However, the first seems better to me. It integrates better into our provisioning flow and better protects the data from accidental change.
The first puts the info in files on a special read-only partition mounted at
/data/rom. This can partition can be written during TPM provisioning, well before the rest of the firmware is flash.The second puts the config in files in
/data. Sentinel values in the firmware image must be replaced with real values before burning to a router card.Approach 1
Data
Put the info in files in a special read-only partition mount at at
/data/rom(or maybe just/rom). Such files are easily consumed by other services on the card, but cannot be modified./data/rom/serial_number- serial number in one line/data/rom/mac_address/self- the mac address that the card will present to the host/data/rom/mac_address/wifi- the mac address that the WiFi chipset should useProvisioning process
Write a program or script to create the "rom" partition image given the specific values for each file. (Perhaps by modifying the idea in approach 2).
When provisioning the TPM on the router card, write that image as the first partition on the flash
This partition should probably go after the memory reserved for the actual firmware. Otherwise, it would be overwritten when the actual firmware is flashed. Note as well that the offset must be a page boundary.
Now the router card is provisioned with all its static values (keys in the TPM and serial number, MACs, etc in the flash parition).
Later, the actual firmware can be written to the rest of the flash.
There are some details to work out here, but I like that the static values can be provisioned early in the router cards life, well before the firmware. That will be helpful in development, where we are frequently changing firmwares but don't want to change the device's static values.
Approach 2
Data
Put the info in files in the
/datapartition. Such files are easily consumed by other services on the card and will persist across firmware updates./data/serial_number- serial number in one line/data/mac_address- the mac address that the card will present to the host/data/wifi/mac_address- the mac address that the WiFi chipset should useProvisioning process
I propose building the firmware image with sentinel values in these files. Before writing the firmware to a router card, replace the sentinel values with the actual values.
For example, a Xaptum serial number is 14 digits long:
XRW02518000020. So in the master image,/data/serial_numbercan contain@XAPTUMSERIAL@. Before writing the firmware to a device, create a copy and replace@XAPTUMSERIAL@with the actual serial number.The actual serial number will be read from a QR-code on the router card label during firmware provisioning.
MAC addresses are 17 digits in human-readable form:
01:23:45:67:89:AB. So the master image/data/mac_addresscould contain@MACADDRESS_MAIN@and/data/wifi/mac_addresscould contain@MACADDRESS_WIFI@.We will register an OUI (MAC address prefix) with the IEEE, allowing us to create MAC addresses. We'll need to figure out a process for managing that generation process.
It might be easier for development if the sentinel values were valid serial numbers, MAC addresses, etc. That would be an easy change.
Tasks
datarootfs overlay.