NetSD: Remote Access to Integrated SD Cards of Embedded Devices

09/29/2021
by   Valentin Schröter, et al.
Universität Potsdam
0

Digitalization continuously pervades all areas and the Internet of Things (IoT) is still on the rise. This leads to an increased need for efficiency in the development of embedded devices and systems composed thereof. Hybrid testbeds are common environments to representatively assess, e.g., hardware-software interaction, interoperability, and scalability. Although automation is inevitable to achieve efficiency, not all devices offer interfaces to be fully software-controlled. Most notably, block devices tend to be inaccessible for software outside a Device under Test (DuT), especially when the latter is in a dysfunctional state. This paper introduces the Networked SD card (NetSD) which enables remote access to removable block devices. The proposed system consists of a hardware part, which enables multiplexed access to a block device (e.g., an SD card) and a software part which enables remote access to the block device (e.g., via HTTP or network block device). NetSD thus adds testing and automation possibilities to DuTs without the need to modify their hard- or software. During the hardware design, we fund that different SD transfer modes and access profiles (read or write focus) benefit from different pull-up resistor configurations for the data lines.

READ FULL TEXT VIEW PDF
POST COMMENT

Comments

There are no comments yet.

Authors

page 4

page 6

05/06/2021

Remote Attestation: A Literature Review

With the rising number of IoT devices, the security of such devices beco...
08/07/2019

A Verified Architecture for Proofs of Execution on Remote Devices under Full Software Compromise

Modern society is increasingly surrounded by, and accustomed to, a wide ...
09/08/2020

Silicon Dating

In order to service an ever-growing base of legacy electronics, both gov...
11/18/2018

WISE: Lightweight Intelligent Swarm Attestation Scheme for IoT (The Verifier's Perspective)

The growing pervasiveness of Internet of Things (IoT) expands the attack...
02/18/2019

Topics of Concern: Identifying User Issues in Reviews of IoT Apps and Devices

Internet of Things (IoT) systems are bundles of networked sensors and ac...
05/04/2021

Automated Driver Testing for Small Footprint Embedded Systems

Embedded systems represent a billionaire market and are present in most ...
02/22/2013

LFTL: A multi-threaded FTL for a Parallel IO Flash Card under Linux

New PCI-e flash cards and SSDs supporting over 100,000 IOPs are now avai...
This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

I Introduction

In modern days, all areas of daily life experience shift towards more digitalization. Systems are increasingly computer-aided and interconnected. This also affects safety-critical areas, like the railway industry. Besides the positive effects like increased efficiency and comfort, the aforementioned shift also comes with the challenge of more complexity and thus more potential causes for defects. This indicates that especially in the area of safety-critical systems, testing the systems under development and their interplay with other systems need to be a first-class concern throughout their whole life cycle.

Especially for railway infrastructure, large-scale testing of the interoperability of digital devices is a relatively novel challenge. So far, there were only a few players on the infrastructure market selling their products. For this small amount of devices and interfaces, manual interoperability testing was feasible. But due to new open standards, like from the EULYNX initiative111https://www.eulynx.eu/ (accessed 2021-07-07), the market opens for new players and their devices. This circumstance increases the need for automated testing, as the large number of devices, interfaces, inter-dependencies and synergistic effects make manual testing insensible.

A common way to test the interoperability of software together with the underlying hardware is testing in hybrid testbeds. A testbed like Marvis[3] provides a representative and scalable execution environment for hybrid tests. Therefore, techniques like simulations, virtualization, and hardware-in-the-loop (HIL) are used [1]. A device under development becomes the dut to interact with a set of other devices, in order to test if the behavior and communication are interoperable. Together with the traffic simulator SUMO222https://sumo.dlr.de (accessed 2021-07-07), Marvis can execute railway scenarios, each containing a new configuration and a new set of connected devices to test various workflows for the dut.

This requires, that the dut is easily reconfigurable (e.g., firmware version, network configuration, software version). The reality shows, that easy reconfiguration is mostly not supported by embedded systems. It is rather the contrary, that remote access to the configuration is prevented by the system hardware and software design. This reduces the risk for attacks but also limits the capabilities for automated testings.

To add the capability of automated configuration for devices, which are by default not able to be reconfigurable in an automated way but contain a block storage device for configuration, we suggest the netsd, a remotely accessible block storage device. The project arose from the use case of improving the automated testing capabilities of a railway axle counter, which stores its configuration data on integrated block storage that is not accessible remotely. netsd makes the block storage device — including the possibly contained file systems and files — remotely accessible without physical access to the device itself. Besides remote access, netsd also enables the injection of faults at hardware level, which opens new possibilities for testing storage hosts.

The following paper is structured as follows: section II provides an overview of other solutions of remotely accessible block storage devices. Section III describes the details about our hardware implementation. Section IV evaluates the performance of the previously described implementation. Section III-D shortly illustrates the software enabling remote access. Section V summarizes the capabilities of the implementation to fulfill our use case and concludes the paper by giving an overview of future work.

Ii Related Work

Around the year 2014 remote SDs333 like Toshiba FlashAir, Transcend Wi-Fi, Eye-Fi mobi and ez Share were popular in the area of photography. These SDs have WiFi capabilities directly on board to access the camera’s file storage. Thus they would be a valid choice for just transferring data from and to a host device. However, WiFi SDs have multiple problems:

  • Remote SDs only work when the host device is powered. It would not be possible at all to access the SD when the host device is switched off.

  • They are running a custom and inaccessible firmware. Modifications would require reverse engineering444 For example:
    http://haxit.blogspot.com/2013/08/hacking-transcend-wifi-sd-cards.html (accessed 2021-07-07)
    .

  • The connection settings like IP addresses, the WiFi SSID, and passwords are stored on the SD itself. For any changes, it is required to remove the SD from the dut.

  • On the other hand, WiFi SDs could not grant exclusive data access nor the guarantee, that there is no data corrupted during the operation of embedded systems.

WiFi SDs could be sufficient for specific applications. However, the option to access data while the device is turned off is already missing for our use case. Apart from this, we would not have any possibility to expand the functionality regarding advanced testbed features that are presented in section V V Conclusion and Future Work.

Besides WiFi SDs, to the best of our knowledge, we haven’t found any closely related publications concerning direct network-accessible block storage devices.

Iii Implementation

The project goal includes, that netsd enables remote access to the block storage without the need for modifying the software of the dut. This aspect of the project is especially important for complex systems like railway infrastructure devices, that are not open source or easily adaptable. netsd must not interfere with the actual operation in any unintentional way. Thus, while expanding the SD with remote capabilities, it should appear unchanged and be controllable from the dut via the same interface.

This leads to the two relevant aspects of the project:

  • Implement a device enabling network access to an SD.

  • Implement a mechanism to enable shared access to the SD from both our rag and the dut while maintaining the same interface for the dut.

For simplicity, we limit our system to SDs, although embedded devices might also use other technologies, such as cf cards. However, some embedded devices, like the axle counter from the initial use case of the project, store its configurations on cf cards. Nowadays, SDs appear to be the most common and various adapters to convert between the different interfaces are available, e.g., cf-to-SD. The decision to base netsd on SD technology aims to make the project applicable for a wide range of devices — be it directly or through adapters. In the following, we use the term SD to not only refer to SD cards themselves but also to refer to block storage technologies having adapters to SDs.

Figure 1 shows the system architecture. Our device, depicted on the right, implements both the remote and the shared access part.

Fig. 1: Architecture of a netsd setup. The SD of the dut is relocated to netsd and netsd is connected to the dut via an extension cable. This enables SD access via the remote access gateway.

Since netsd is intended for development, fault injection, test automation, and alike purposes, neither hardware nor software security are of concern in this project.

Iii-a Remote Access Gateway

To allow remote access, netsd is based on a microcontroller with network capabilities. Nowadays, there are various microcontrollers and single-board computers offering onboard WiFi, like the Raspberry Pi 4, the ESP32 microcontroller or the wireless STM32 series. For this project, we decide to use an ESP32 that can connect to existing networks as well as creating an own access point. As a small-sized, low-level microcontroller with 4 MByte Flash, 320 KByte RAM, and a 160 MHz dual-core processor, it has enough performance to handle simple storage tasks on the SD and also offers fast WiFi performance. In contrast to a Raspberry Pi, the ESP32 also provides real-time capabilities out of the box which is important for timing aspects of, e.g., storage protocols.

Iii-B Physical Shared Access

The shared access implementation is the main part of our contribution. The following problems arise if multiple devices should have simultaneous access to the same SD:

  • The shared access must support the dut and netsd having different voltage levels. As the SD interface is specified to operate between 1.7 V and 3.6 V[2, p. 6] we cannot assume both devices having the same voltage.

  • Shared access must not lead to short circuit faults. While well-implemented SD devices should not endanger system short circuits, custom embedded systems still carry the risk to create short circuits if both devices try to access the SD simultaneously.

  • Non-exclusive shared access can create data conflicts, as simultaneous operations from both devices can lead to failed transmissions.

Due to these problems, a simple electrical connection of all SD data lines between the dut and our device would be neither safe nor reliable in operation. To ensure a functioning shared access, we introduce the SD switch. This part of netsd can grant explicit and exclusive access to the SD, either to the dut or to our rag. Therefore it is possible to let the dut access the SD by default and just revoking the access for a short time if we have to change data by our rag. While the SD switch ensures exclusive access to the SD, it cannot guarantee the dut to always access the SD if required. During access from our device, operations on the SD from the dut will fail and have to be repeated.

An SD contains 6 data lines and 2 power lines[2, p. 12]. The SD switch allows to switch on and off bidirectional communication on all data lines as well as switching the power source so that the respective connected device can perform hard resets of the SD. For switching, multiple electrical components can be considered, while mainly relays, transistors, and MOSFETs are relevant. Table I lists the advantages and disadvantages of each technology.

Component Advantages Disadvantages
Relays Easy to design bidirectional switch. Certainty of electrical separation. Slow control speed. Switching needs a lot of energy. Big component size.
Transistors Fast control speed and high signal transmission frequencies. Small component size. Decrease in voltage affects the interface. Complex electrical network to allow bidirectional switch.
MOSFETs Fast control speed switching and high signal transmission frequencies. No changes in signal voltage. Small component size. Complex electrical network to allow bidirectional switch.
TABLE I: Comparison of electrical components for switching signals.

The simplest way to implement an electrical switch would be to use relays. However, relays as mechanical components are comparatively large, which would accumulate for six data lines per connected device. A MOSFET on the other side is a non-mechanical, cheap and small-sized component. An important requirement for switching bidirectional interface lines is the consistency of the voltage levels. In contrast to a normal transistor, a MOSFET exactly offers this voltage consistency. That leads to using a MOSFET as the preferred choice for the SD switch basis. Nevertheless, to ensure a safe electrical separation if the SD switch should disconnect a single device, multiple MOSFETs and other components must be combined in a complex electrical circuit. But, as analog switching is a default task in electronics, there exist ic offering the desired bidirectional switching functionality with safe electrical separation. For this project, we chose the 74LVC1G66-Q100 circuit from Nexperia555 See https://www.nexperia.com/products/automotive-qualified-products-aec-q100-q101/automotive-logic/switches-multiplexers-de-multiplexers/series/74LVC1G66-Q100.html (accessed 2021-07-07) for Product specifications. Most other analog switches also from other companies would work too..

Figure 2 depicts how analog switches are used to ensure electrical separation for both devices. All signals of the SD are connected to two sets of switches, one set for the dut on the right and one set for our rag on the left. Both switch sets contain a single switch for each of the six data lines666see fig. 3 for an overview of the SD data lines from the SD. All switches are controllable by our rag, which takes care of which side currently has granted access to the SD.

Fig. 2: Simplified circuit diagram. Each SD data line is connected to both devices via analog switching ic. It can thus be controlled to which device the SD is connected.

Iii-C SD extender cable

To relocate the physical SD to netsd, an extension cable is used, that simulates the SD in the actual slot of the dut. The extension cable uses crosstalk avoiding signal arrangement, which can be seen on the right side of fig. 3. This arrangement inserts a GND line between each data line, minimizing the mutual influence of signals.

Fig. 3: Left: Connection lines of an SD. Right: Connection lines of the extension cable, where a GND line is placed between each data line of the extension cable to avoid crosstalk.

For low-frequency signals (around 10 MHz) it is possible to use the exact same arrangement as the contacts from the SD, which can be seen on the left side of fig. 3. However, since the native SD interface is specified to transfer data with up to 208 MHz [2, p. 1] these direct adjacency of signal lines leads to interference in the transmission. Thus the crosstalk avoiding signal is important to meet tighter timings and allow reliable transmissions from host devices to the SD.

Iii-D Software

To enable accessing data on SD via our rag with software, netsd needs to offer software interfaces to the network. We implemented two different software interfaces for remote access which are described below. The ESP32 itself can communicate with the SD through an spi and through the native SD interface[2, p. 12 ff.]. Both interfaces allow unrestricted access to the SD.

Iii-D1 Rest Api

: The first method is a simple REST API. The API offers request endpoints the cover all basic file level operations. This enables simple and platform-independent communication with the connected SD.

Iii-D2 Network block device

: The second method for remote access is the Network Block Device (NBD) protocol. This network protocol allows Linux systems to mount remote storage devices as virtual block devices. Once mounted, an SD can be accessed like normal other mounted devices at a block level. Therefore using NBD we can work with the remote SD like a normal directory in our local file system, but also flash full images to the SD. One drawback of NBD is the dependence on using Linux as the operating system. However, NBD is also available on Windows Subsystem for Linux (WSL). Furthermore, the data can also be made available to other platforms via protocols such as WebDAV.

Iii-D3 System flow chart

: Figure 4 illustrates the normal operation process that allows exclusive access to the block storage. By default, the dut has access to the SD. Our system is waiting continuously for incoming requests. On a request, the access to the SD is switched to our rag, enabling the execution of requested operations. After these operations are finished, the access is switched back to the dut. Between each change in access to the SD, it is repowered to allow reinitialization to the communication interface. This hard reset would not be necessary if concurrent access is implemented like described in section V V Conclusion and Future Work. For the project’s use case with the axle counter, the device itself will not be turned on until corresponding operations are executed by our device, since the axle counter only read configuration files when starting it. This procedure however is implemented by the main testbed application that embeds netsd.

Fig. 4: Flowchart of normal operation of netsd. In normal operation, only one device is given explicit access to the SD at a time.

Iv Evaluation of the hardware prototype

A switch circuit between the physical SD and an accessing device inevitably influences the electrical properties of the data lines. Especially for dut with fast data transfer requirements, this influence must be as low as possible. This section presents the hardware quality for the following test conditions:

  • SD: Intenso microSDHC, 8 GByte, Class 10 (min. 20 MByte/s read throughput, min. 12 MByte/s write throughput).

  • Test tool: MiniTool Partition Wizard777 https://www.minitool.com/partition-manager/partition-wizard-home.html (accessed 2021-07-07) on Windows 10 operating system testing with different data block sizes. Since the evaluation does not test the remote data throughput, but the signal quality for a DuT connected to an SD via the switching circuit, no NBD is required.

  • Baseline test: Windows 10 computer as dut with the SD directly plugged in, also without an extension cable.

  • Test of our SD switch: Windows 10 computer as dut with access to the SD through our SD switch.

  • SD switch specification: 74LVC1G66 as switch ICs, 48cm long extension cable with crosstalk avoiding signal arrangement, and two different pull-up resistor configurations for the hardware (see below).

SD interfaces operate with open-drain I/Os888 Open-drain I/Os do not actively set both signal states (low and high voltage levels for digital 0 and 1). In the case of SDs, signal lines are only actively drawn to GND for digital 0. For digital 1, the signal line voltage is not actively set to a high level, but just released to a default state. . These open-drain I/Os require a default voltage level on the signal line induced by the usage of pull-up resistors. Normally, pull-up resistors are present on the side of the host device. However, since the physical SD is relocated by an extension cable and the switch ic into netsd, these host pull-up resistors are not sufficient to guarantee steep signal edges. This consideration leads to two different hardware configurations, either by just using the already existent pull-up resistors of the host device (visualized on the bottom of fig. 5) or by explicitly adding pull-up resistors on netsd to improve signal quality (visualized on the top of fig. 5). To test and debug these different hardware configurations we created an evaluation board that is visible in fig. 8.

Fig. 5: Different hardware setups for data lines on netsd. Top: Explicit pull-ups are added on all sides of the analog switches for steeper signal edges. Bottom: No explicit pull-ups are added on side of the dut, which provides itself integrated pull-ups.
Fig. 6: Read throughput with different block sizes and hardware configurations. Throughput increases up until a block size of 64 KByte, where it is ~3 times higher without explicit pull-up resistors than with and ~72% of the baseline throughput.
Fig. 7: Write throughput with different block sizes and hardware configurations. Throughput increases up until a block size of 64 KByte, where it is ~2 times higher with explicit pull-up resistors than without and ~40% of the baseline throughput.

The first test evaluates the read throughput of the SD. Therefore we compare the read throughput through our switch with and without an explicitly added pull-up resistor with the baseline read throughput, where the SD is plugged directly into the host device. Figure 6 visualizes the following read throughput results:

  • The read throughput generally increases with larger block sizes (with a cap at >64 KByte block size).

  • The read throughput without pull-up resistors is proportional to the baseline throughput.

  • The read throughput with pull-up resistors is 30% to 65% worse than the read throughput without pull-up resistors.

The read throughput test especially shows better performance without explicitly added pull-up resistors. This can be explained with different bus speed modes of the SD. The normal speed mode operates at 3.3 V, the same as the supply voltage, which is used for the pull-up resistors too. However, if both the host device and the SD support the UHS (ultra high speed) mode, the bus operates at 1.8 V. Without explicit pull-up resistors, this UHS bus mode is automatically selected, resulting in much higher read throughput which is decreased only by the actual hardware delay (extension cable and switch propagation delay) compared to the baseline. On the other side, if pull-up resistors at 3.3 V are added, the UHS mode cannot be selected, resulting in lower read throughput.

The second test evaluates the write throughput of the SD. Again, we compare the write throughput through our switch with and without an explicitly added pull-up resistor with the baseline write throughput. Figure 7 visualizes the following write throughput results:

  • The write throughput generally increases with larger block sizes (with a cap at >64 KByte block size).

  • The write throughput without pull-up resistors caps at 32 KByte block size and decreases afterward.

  • The write throughput with pull-up resistors is better than without pull-ups at block sizes greater than 32 KByte.

The write throughput test shows an opposite behavior. Up to a block size of 32 KByte, the throughput without pull-up resistors is slightly better, but afterward, the write throughput with pull-up resistors becomes much better. This can be explained by the initial thought of signal degradation if no additional pull-up resistors are installed. Without pull-up resistors, the UHS mode at 1.8 V is used. At this low voltage, signal edges become unclean through the long extension cable. Especially at higher block sizes, this degraded signal quality leads to a higher rate of transmission errors. These failures result in the data rate cap at a block size of 32 KByte. On the other side, even though the host does not use the UHS mode if explicit pull-up resistors are added, the signal quality becomes much better, allowing higher write throughput.

In summary, different hardware configurations can take into consideration for different settings. If the dut does not support the UHS mode at 1.8 V, you should add 3.3 V pull-up resistors to improve overall signal quality. However, if the dut supports the UHS mode, the main operation mode is decisive for the decision, whether to use or not to use pull-up resistors. If primarily read operations are executed, omit the pull-up resistors to achieve higher read throughput. If primarily write operations are executed, use the pull-up resistors to enforce the 3.3 V mode to achieve higher write throughput.

Fig. 8: The designed evaluation board for the project. The board focused on offering various debug and configuration possibilities.

V Conclusion and Future Work

netsd has been developed to fulfill our mentioned use case with the axle counter. The concept proved to be useful and further, netsd can aid development practices and test automation of embedded systems in general.

V-a Remote access for general purposes

Any embedded device using an SD (or block storage device with a corresponding adapter available) but not providing remote access to that storage device could be extended by netsd. As explained above, netsd is not intended to replace existing remote technologies that are integrated into systems. netsd rather aims to expand existing systems that are not capable of remote storage access, without changing hardware or software of such systems.

V-B Storage multiplexing for embedded systems

The introduced switch part of netsd allowing shared access to the SD could serve as a basis to multiplex a single block storage device between two or more hosts. Multiple bus switches (one set of switches for each device) would allow safe access to the same physical SD for all connected systems. This could be used to accumulate data from multiple hosts or to load the same data (e.g., configurations) to multiple hosts.

V-C Fault Injection

The capabilities of the netsd hardware prototype offer unprecedented prospects for software-controllable hwifi[5]. The forceful insertion (injection) of suspected error causes (faults) is a well-established approach in testing hardware and — increasingly — software. Having control over all data lines independently can be leveraged to test hardware (e.g., SDs, host controllers) and software (e.g., device and file system drivers). Single data lines can be disconnected for short amounts of time to test hardware and software fault tolerance (e.g., error-correcting codes). Our hardware implementation also allows for modification of the signals on the data lines, such as replaying or corrupting data. Experiments can thus not only assess crash fault models, but more complex fault models, including computation, omission and timing faults [4]. It can be suspected, that with more general error classes, more hardware and software misbehavior can be identified.

V-D Future work

The original concept of shared access in netsd implied mutually exclusive access: if one device has access to the SD, the other does not. Originally, this also implied a hard reset to reset the interface settings of the SD after each access switch.

With knowledge about the host device and the use of the same interface settings, this principle could be expanded for enabling parallel access. Instead of switching all lines (incl. the power lines) after switching to the other host device, the system could just switch the data lines without resetting the SD. However, besides the need to have the same interface settings for both host devices, this method can be expected to only work in highly controllable environments. E.g., since commonly used file systems do not support parallel access at block level, this approach carries the risk of data corruption.

Instead of implementing parallel access to the SD on a hardware level, it could be realized in software to circumvent the aforementioned shortcomings. For such a software SD to work, a microcontroller could emulate an SD interface via its GPIO lines. The microcontroller would have exclusive access to the physical SD, so it can safely handle parallel requests from the dut and the rag. The challenges with this approach are the implementation of the SD protocol stack and a microcontroller offering IO capabilities fast enough to create the illusion for the hosts to communicate with a physical SD. Since the SD interface is specified to transfer data at up to 208 MHz [2, p. 1] the currently selected ESP32 microcontroller would be too slow for higher frequency modes and therefore not suitable for this approach. As an extension, the physical SD could be replaced with a network share.

Acknowledgment

The authors would like to thank Tobias Zagorni for his active development and testing of netsd.

References

  • [1] M. Abbas, R. Jongeling, C. Lindskog, E. P. Enoiu, M. Saadatmand, and D. Sundmark (2020) Product line adoption in industry: an experience report from the railway domain. In Proceedings of the 24th ACM Conference on Systems and Software Product Line: Volume A-Volume A, pp. 1–11. Cited by: §I.
  • [2] S. Association (2020) SD specifications part 1 physical layer simplified specification. version 8.00. Note: https://www.sdcard.org/downloads/pls/pdf/?p=Part1_Physical_Layer_Simplified_Specification_Ver8.00.jpg&f=Part1_Physical_Layer_Simplified_Specification_Ver8.00.pdf&e=EN_SS1_8Accessed: 2021-05-26 Cited by: 1st item, §III-B, §III-C, §III-D, §V-D.
  • [3] J. Beilharz, P. Wiesner, A. Boockmeyer, F. Brokhausen, I. Behnke, R. Schmid, L. Pirl, and L. Thamsen (2021) Towards a staging environment for the internet of things. In 2021 IEEE International Conference on Pervasive Computing and Communications Workshops and other Affiliated Events (PerCom Workshops), pp. 312–315. Cited by: §I.
  • [4] F. Cristian, H. Aghili, R. Strong, and D. Dolev (1995) Atomic broadcast: from simple message diffusion to byzantine agreement. Information and Computation 118 (1), pp. 158–179. Cited by: §V-C.
  • [5] P. Yuste, J. C. Ruiz, L. Lemus, and P. Gil (2003) Non-intrusive software-implemented fault injection in embedded systems. In Latin-American Symposium on Dependable Computing, pp. 23–38. Cited by: §V-C.