@ -5,15 +5,15 @@ Requirements were clearly defined by Magrathea Laboratories demands to provide l
Such components include but are not limited to door sensors, power sockets, temperature sensors, projectors and screens who are all managed by a home-automation controller, which is driven by the software \textit{home-assistant}\cite{HASS}.
It provides direct control over all existing components using a web UI and allows to define rules and automations on how these components interact.
For the components hardware, boards based on the \textit{ESP8266} micro-controllers, mostly \textit{ESP-01s}\cite{ESP-01s} boards, are used in combination with self-developed power supplies and use-case specific hardware components.
For the component's hardware, boards based on the \textit{ESP8266} micro-controllers, mostly \textit{ESP-01s}\cite{ESP-01s} boards, are used in combination with self-developed power supplies and use-case specific hardware components.
These boards feature a small and robust design, achieve very low power consumption and integrate WiFi without requiring any extra components.
It integrates a Tensilica L106 32-bit micro controller unit (MCU) with a maximum CPU performance of 160 MHz, 64 kB instruction memory and another 96 kB of main memory.
According to the manufacturer, it is among the most integrated WiFi-capable chips in the industry.
For these boards, a common software platform referred to as \textit{ESPer}\cite{ESPer} has been developed.
The software is based on the \textit{Sming}\cite{Sming} library, which in turn is based on the opensource SDK for \textit{ESP8266} and integrates a lot of other software components for easy use.
The software is based on the \textit{Sming}\cite{Sming} library, which in turn is based on the open-source SDK for \textit{ESP8266} and integrates a lot of other software components for easy use.
To build the software, a \textit{Makefile}\cite{make} is used, which provides a simple way for reproducible builds.
The base topology used is shown in figure \ref{fig:topology}.
The base topology used is shown in Figure \ref{fig:topology}.
For communication with the controller, the \textit{MQTT}\cite{MQTT} protocol is used.
It provides a lightweight messaging mechanism implementing the publish-subscribe pattern that allows devices to listen for commands and publish their current state to the controller and other interested parties.
The controller software has out-of-the-box support for this protocol, which allows easy integration of all different device types using the same patterns.
@ -11,7 +11,7 @@ All these devices should then download and install the new software version and
Even if the installation of an update fails in the middle of reprogramming the controller, the system should continue to work fully functional immediately and after a reboot.
\item Downloading the updated firmware should be done over the WiFi interface using the same network connection as used during normal operation.
Fetching the firmware should be done side-by-side with other traffic produced during operation.
Fetching the firmware should be done side-by-side with operational traffic.
\item The update process can happen over any untrusted wireless network or Internet connection without being vulnerable to attackers.
To prevent possible attackers from injecting malicious software into the embedded devices, a cryptographic signature mechanism must be implemented.
@ -5,21 +5,21 @@ This sections describes all three of these parts in detail.
The build-time configuration was extended to include a new option called \texttt{UPDATER\_URL}, which is the base URL used to query the update server.
Each device requires to have this option set to make the update work.
If the option is skipped, the code for update management is excluded during the build.
Skipping the option results in the exclusion of the code for update management during the build.
\subsubsection{Checking for updates}
Initially, each device queries the update server regularly for the current firmware version and initializes the update process if remote and local versions differ.
To do so, the update server provides a file for each device type containing the available version identifier, which is stored beside the firmware binary files.
These version identifier files are provided by the update server using \textit{HTTP 1.1}\cite{HTTP_1.1} under the following path pattern: \texttt{\$\{DEVICE\}.version} (whereas \texttt{\${DEVICE}} is the device type name).
These version identifier files are provided by the update server using \textit{HTTP 1.1}\cite{HTTP_1.1} under the following path pattern: \texttt{\$\{DEVICE\}.version} (whereas \texttt{\$\{DEVICE\}} is the device type name).
The version identifier can be an arbitrary string as the content is not interpreted semantically but only compared to the version identifier used during build time.
Each device tries to fetch the version identifier file once every hour.
After the version identifier file has been downloaded successfully, the whole file content is compared to the version identifier provided during build time.
If the version identifiers differ, the update process is initialized; in cases where the download has failed, the update server or the network connection was not available or any other error occurred, another attempt will be made at the next interval.
In addition to the interval, a special \textit{MQTT} topic shared by all devices is subscribed on device startup: \texttt{\${MQTT\_REALM}/update}.
In addition to the interval, a special \textit{MQTT} topic shared by all devices is subscribed on device startup: \texttt{\$\{MQTT\_REALM\}/update}.
Every time a message is received on this topic, a fetch attempt for the version identifier file is triggered.
This allows faster roll-outs of updates and finer control for manual maintenance.
@ -57,15 +57,15 @@ Therefore, the second ROM can not be re-mapped to have the same start address as
While the firmware is executed without any dynamic linking mechanism and the chip does not support position independent code, the addresses used in the ROMs are dependent to the offset at which the firmware is stored.
This arises the need for building two firmware binaries, one for each target location.
To do so, a linker script for each of the two ROM slots was created, which is used to create two variations of the same firmware, only differing in ROM placement.
The two resulting firmware binary files are both provided for download via HTTP 1.1 - which one to download depends on the target ROM slot and is selected by the device during the update process.
Listing~\ref{lst:linker_script} shows the only difference between the two linker scripts, where \texttt{\${SLOT}} must be replaced with the slot number according to the current build.
The two resulting firmware binary files are both provided for download via \textit{HTTP 1.1} - which one to download depends on the target ROM slot and is selected by the device during the update process.
Listing~\ref{lst:linker_script} shows the only difference between the two linker scripts, where \texttt{\$\{SLOT\}} must be replaced with the slot number according to the current build.
In addition to the two ROMs, the flash must provide room for the bootloader and its configuration.
\textit{rBoot}\cite{rBoot} has been choosen as it is integrated within the \textit{Sming} framework and allows to boot to multiple ROMs.
For configuration, an \textit{rBoot} specific structure is placed in the flash at a well-known location directly after the space reserved for the bootloader code.
This structure contains, among other things, the target offsets for all known ROMs and the number of the ROM to boot from on next reboot.
The full memory layout of this approach is shown in figure~\ref{fig:memory_layout}.
The full memory layout of this approach is shown in Figure~\ref{fig:memory_layout}.
To calculate the origin of application data for each slot, the available memory of 1 MB is split in half and an offset of the size of the bootloader code and its configuration (0x2000 bytes) is added.
For alignment and easy debugging, the second block is also shifted by the same amount ob bytes as the first block.
The unused gap of 8192 bytes is used by some applications to store data which can persist over application updates.
