CerberOS:

Table 2. Possible app contract resources, their type and  what they specify.
Resource Type Specifies
RAM value Amount of dynamic memory for the app ROM valueAmount of storage memory for the app Peripherals  listPeripherals the app has access to Network value Amount of bandwidth for the app Priority0-255 App priority in the scheduling queue
Lease value Amount of time the app is on the device
4.4Instruction Monitoring and Execution
Key to CerberOS is runtime interpretation of the code for instruction-level monitoring of apps. During bytecode exe- cution of an app, the interpreter first checks the contract and the buckets related to the app to determine if it is allowed to execute that bytecode. Resource checks have a modifiable granularity, depending on the bytecode. For example, Cer- berOS can check every ten instructions if the allowed number of operations has been reached. This is a trade-off between accuracy and the overhead of instruction-level monitoring. If the contract is violated, CerberOS prevents further execu- tion and handles the app (e.g., by removing it or replacing the instruction). If the instruction is allowed, it interprets the bytecode and executes it. The bottom part of Figure 3 shows the flow of a bytecode instruction through the interpreter.
4.5CerberOS API and Platform Support
CerberOS is a general solution that works with various hardware platforms and OSs and provides Java apps con- trolled access to board functionalities. Apps use the API from UJApp to, for example, set timers or interact with pe- ripherals.  This layer of indirection between apps and the
µJVM  simplifies  adapting  apps  to other platforms.The
µJVM makes select native C functions accessible to UJApp through Java stub classes which serve as drivers for UJApp and the extending apps. They contain no implementation but form the link to the BSP. The BSP is the layer of indirec- tion between the µJVM and the hardware board and under- lying OS functionality, if any. Integration with another OS is optional. If not desired, the BSP itself needs to imple- ment desired features on top of the hardware board such as scheduling, timers and networking.
Accordingly, porting to a platform requires four changes:
(i)creating a BSP which accesses the OS and board features,
(ii)integrating the µJVM in the OS scheduler, if present, or scheduling itself if not, (iii) implementing Java stub classes to make them accessible to UJApp, and (iv) extending UJApp with the new functionalities, if any.
We have implemented CerberOS with an integration of Contiki on the µPnP board [30] with an ATmega1284P mi- crocontroller (MCU), as a stand-alone edition for the Zig- duino platform with an ATmega128RFA1 MCU and for a regular Windows PC. For the stand-alone version, the BSP provides direct access to the devices hardware. Only Cer- berOS is running and controls its own timers, scheduling and duty-cycling. For the Windows version, the BSP pro- vides standard board features using the Windows API. For the µPnP version, the BSP leverages existing Contiki and
µPnP features. Here, the µJVM is a process that runs on Con- tiki and is scheduled in its cooperative process design [9] and uses the µPnP network stack. The µPnP version with Contiki is our main test and evaluation platform.
4.6Scheduling and App Management
There are two levels of scheduling: at the VM-level for apps and at the OS-level for the µJVM and other OS tasks. VM scheduling is multi-threaded where apps (i.e., threads) run in their own context, manage their own stack and can be context-switched by yielding or preemption. Therefore, CerberOS provides preemptive multi-threading for apps even
when the BSP underneath uses an event-driven scheduler. OS scheduling can be implemented by CerberOS or through the integrated OS. CerberOS uses the scheduler in Contiki which allows to suspend the µJVM when all apps are idle.
Apps are scheduled consecutively in a fixed circular queue, in order of load time on the node. An app executes for a time slice, defined by the priority specified in its con- tract, and then the scheduler switches to the following one. Since the position of an app in the queue is fixed, all apps are guaranteed to run. An app can also yield, wait or termi- nate itself. Yielding stops the execution of the app, allowing the next one in the queue to go. Waiting is based on events such as communications or timers and means the app will be skipped in the queue while it is waiting. If the event occurs during the execution of another app, the app will stop wait- ing and run the next time it is reached in the queue. If all apps are waiting, the node sleeps to conserve power.
We do not support real-time requirements for apps as-of- yet. However, a node controls its runtime by managing the apps and can therefore control the timing of app execution. It could support soft-real time requirements by being strict in what apps it accepts. Exploring scheduling and timing in terms of apps and their contracts is future work.
5Evaluation
We evaluate CerberOS on key metrics of constrained nodes: memory size of the base image, execution perfor- mance, app code size and battery lifetime. We analyze these metrics for representative benchmarks and two realistic IoT use cases, including a multi-app deployment.
We implemented CerberOS on top of µPnP, a full-featured IoT platform [30], with Contiki 3.0 on the ATmega1284P board, an 8-bit MCU with 128KB flash, 16KB RAM and clocked at 10MHz. µPnP motes offer 802.15.4e mesh net- work support via a SmartMesh IP radio [28]. Evaluation on
µPnP provides an efficient network stack and access to Con- tiki features such as timers and an I/O API. In addition, it demonstrates the feasibility and generality of our approach to enable resource-secure multi-app IoT platforms on rep- resentative constrained hardware and software. Finally, we compare CerberOS with the TakaTuka and Darjeeling JVMs as a point of reference. Metrics and figures for these JVMs come from existing research [1, 6, 10, 20]. They are not di- rectly comparable since they use different platforms, apps and implementations and support other features. However, the comparison serves to provide insight into overall perfor- mance of embedded VMs and to further demonstrate the rea- sonableness of our resource-secure µJVM.
5.1Memory Impact of CerberOS
CerberOS requires additional RAM and ROM on top of the BSP and, if applicable, integrated OS. This analysis does not consider the memory cost of apps, which is discussed  in Section 5.3. CerberOS is modular and can turn off sup- port for Java features, such as exceptions or 64-bit floating point operations. Therefore, we compare three cases: (i) the memory size of a minimal implementation of µPnP, (ii) the memory size of a minimal CerberOS implementation which drops support for floating point calculations, 64-bit long val- ues, advanced exception handling and Java thread synchro-
Table 3. Memory cost in ROM and RAM in bytes for versions of CerberOS and their difference.
ROM RAM ∆ROM ∆RAM
Minimal µPnP 98661731 - -
Minimal CerberOS 391764574 293102843
Full CerberOS 644584616 2528242
Table 4. Execution times of C and Java apps in millisec- onds and their ratio.
C Java Java/C Ratio Encryption 3.963ms205.420ms 51.829
Storage 166.1ms169.6ms 1.024
Network 12.074ms15.782ms 1.307
Sensing 69.260ms71.150ms 1.027
nization, and (iii) the memory size of a full CerberOS imple- mentation with CDLC-compliance. Minimal µPnP features a network stack, timers and Contiki scheduling functional- ity. CerberOS integrates this with our design (discussed in Section 4) and provides multi-app management, resource se- curity and Java support. We compile with the “avr-gcc” toolchain, version 4.9.2, and optimize for size and speed. Code size is given by the “avr-size” tool. App file size is evaluated separately in Section 5.3.
Table 3 shows the three cases in terms of ROM and RAM and the difference between consecutive versions. µPnP uses around 10KB ROM and 2KB RAM. Minimal CerberOS re- quires an additional 30KB ROM and 3KB RAM. Full Cer- berOS needs an extra 25KB ROM and negligible added RAM. The total size of the full-featured solution is around 65KB ROM and 5KB RAM. Accordingly, CerberOS is fea- sible for Class-1 devices [5] and a minimal implementation can even be used on more constrained devices.
The memory cost of TakaTuka and Darjeeling is around 40KB-60KB ROM and 0.5-4KB RAM, depending on the app.  These figures are comparable with CerberOS, tak-  ing into account the level of Java compliance and trade-offs made between the µJVMs. TakaTuka achieves its low RAM usage by customizing JVM bytecode support down to the set used by the given program. This complicates adapting the platform over time and prevents our security features.
5.2CerberOS Execution Performance
CerberOS impacts software execution performance due to bytecode interpretation overhead for individual apps and context switch time between apps.
5.2.1Bytecode interpretation performance
We measure the performance overhead of interpretation in six benchmarks, implemented in both Java and native Con- tiki C apps. The apps are encryption, storing an array, send- ing a network packet and reading a sensor, which are core IoT device functions; and bubble sort and pin toggle, which serve to determine the µJVM performance characteristics. Fine-grained timings are obtained with a logic analyzer. We use the minimal CerberOS implementation for evaluation.
The core IoT function benchmarks reveal how CerberOS performs for typical IoT device duties. The encryption test measures the time to encrypt and decrypt a value. This is commonly the most computationally heavy task a node does for standard IoT apps. We use the lightweight Speck block cipher [3], developed by the NSA for high performance on constrained hardware and software, and implement it com- pletely in Java. Speck has been tested on our range of plat- forms (8-bit ATmega) and generally outperforms other IoT block ciphers [8]. The test uses a 128-bit key to encrypt a 64-bit block consisting of two random 32-bit values. The
storage test measures the time to write a 50-byte array as a block to flash. The network test measures the time to send  a 50-byte payload packet to the gateway. Only the time to send the packet is measured, since the response time is de- pendent on the network. The sensor reading test is a sensor measurement from a sensor peripheral. It measures the time to communicate over the I2C bus to get the sensor value.
Table 4 shows the execution time of the core IoT func- tion apps in milliseconds and the Java/C ratio. The storage, network and sensing evaluation show comparable execution times despite the overhead of virtualization since they call native functions made accessible by the BSP. The overhead incurred is through code interpretation and the resource con- tract checks on this call. This penalty is significant for short tasks, such as a 30% overhead for sending a packet, but re- mains feasible, in the order of milliseconds. In contrast, the compute-heavy test, encryption, has a significant overhead of about 50x when implemented completely in Java.
The bubble sort benchmark sorts an array of 256 decreas- ing 32-bit integers, the worst-case bubble sort scenario with a time complexity of O(n2). This test is not typical of the duties performed by sensor and actuator nodes but presents a worst-case scenario for a computationally heavy task. Bub- ble sort has a performance penalty of about 300x, 0.164s for C and 46.99s for Java, when implemented completely in Java with no native function calls. Therefore, we consider this the worst-case scenario but unrepresentative for typical IoT apps. The pin toggle benchmark measures the time for a function call to pass through the interpreter. Since we are measuring the time of a trivial operation in C and compar- ing that to an interpreted and controlled operation in Java,  it shows a performance penalty of about 1000x, 0.7µs for C and 0.779ms for Java. This time reveals that the time to call a Java function takes around a millisecond and so forms the lower-bound for any Java operation done by apps.
The cost of interpreting Java versus executing native C code is similar in both Darjeeling and TakaTuka for the worst-case bubble sort example. Darjeeling performs bet- ter, with a cost of up to 113x, and Takatuka performs simi- larly, up to 324x slower. For other apps, the results are simi- lar across the VMs: for compute-heavy tasks a performance penalty of two orders of magnitude is possible.
Evaluation indicates that an interpretation approach is less-suited to compute-heavy tasks implemented completely in Java. However, these tasks are relatively rare in IoT sce- narios due to their impact on battery life. Battery lifetime and app execution time are further compared in Section 5.4. In addition, it is possible to implement common compute- heavy algorithms in C and make them accessible to apps as a board call. Our evaluation shows that this will achieve com-
Table 5. App ROM code sizes in bytes for optimized Java bytecode and for C Contiki ELF format.
C Code Java BytecodeDifference
Table 6. App deployment time to node in seconds, node energy cost in Joule for C and Java apps and difference.
Time (s) Energy (J)Difference
Encryption 31461392 -1754 | -55.8%
 
C Java C Java
(%)
Storage 1894 1108 -786 | -41.5%
Network 2090 1296 -794 | -38.0%
Sensing 1684 963 -721 | -42.8%
IoT App A 32072037 -1170 | -36.5%
parable execution times as when it is implemented purely in C, for example, as in the storage test. Note however that this analysis does reveal that apps with many Java operations or rapid response requirements are out of scope for CerberOS.
5.2.2App context switching performance
Context switching between apps introduces overhead be- cause the scheduler needs to execute and a new app stack needs to be loaded. We measure the time required to switch between apps for different amounts of total apps. The evalu- ation reveals that context switching takes around 2.16ms and that the difference is negligible for more apps, increasing by just 0.98% when going from two apps to seven apps.
5.3App Code Size and Deployment
This section evaluates the code size of apps in CerberOS for ROM and RAM and the impact of this size on deploy- ment time and energy cost. For memory, we only consider the default cost of apps in both ROM and RAM and not the memory resource amount they specified in their contracts since this is variable. Deploying apps on a node efficiently requires OTA code transmission. Thus, deploying apps costs time and consumes bandwidth and energy on the receiver and all intermediate routing nodes. In addition, the destina- tion node has to accept and store the app which costs memory and energy. Therefore, app code size is important for multi- app IoT platforms. In CerberOS, apps are coded in Java, a high-level language, and compiled to an optimized bytecode format which can be directly loaded on a node. Since high- level languages are more compact, this will result in reduced app code sizes, as discussed in Section 4.2.2. For native Con- tiki apps, apps are coded in C and have to be compiled into an ELF module format before they can be dynamically loaded, which incurs a significant size overhead [25].
Table 5 shows the app ROM code sizes of the core IoT functions benchmarks and for a representative IoT app (IoT App A, see Section 5.4). As expected, bytecode requires be- tween 36%-55% less bytes, even though apps in CerberOS have an additional cost in code size because they specify con- tracts. The contract has a fixed one-time cost of around 400 bytes, a significant relative impact for small apps but less im- portant as they increase in size. App ROM code size is the size of the code that has to be transmitted OTA.
Apps also require a default amount of RAM to work. Ev- ery app is a thread which introduces a minimal cost of 218 bytes for the stack. Each app also incurs a non-fixed RAM cost for the contract and buckets. In practice, an app costs be- tween 400 to 600 bytes of RAM, depending on the resources it specifies. Therefore, we support up to seven coexisting apps, since permitting more brings us outside the scope of
Encryption 105.3349.16 2.161.01 −53.2%
Storage 65.24 40.06 1.34 0.82 −38.9%
Network 71.51 46.09 1.46 0.94 −35.6%
Sensing 58.51 35.42 1.20 0.73 −39.2%
IoT App A 107.2869.82 2.201.43 −35.0%
Class-1 devices when accounting for the 5KB RAM cost of CerberOS itself. Up to ten concurrent apps have been tested but can exceed device resource limits.
We obtain energy cost estimates for app deployment using previous research which is based on a 50-node µPnP-Mesh test bed with a maximum hop depth of 3 [21, 25, 30]. Table 6 gives the time and energy for deploying Java and C apps. As expected, Java apps deploy faster and consume less energy, up to 50% savings. This shows the benefits of compact high- level language apps for IoT deployments.
The size of these benefits depends on the frequency of app reconfiguration and app size. As an illustration, we consider the energy saved with CerberOS when deploying a single app. Our analysis shows this varies between 0.5 and 1 Joules for relatively small apps. The µPnP board has a 3000mAh battery at 3.2V, which stores 34560 Joules. If deploying costs 1 Joule less, it saves 0.0029% of the battery capacity per code deployment for the reconfigured node. In dynamic use cases over a multi-year timespan, these savings accumulate. For instance, saving 1 Joule a day saves 5.3% of the battery capacity over five years. In addition, this analysis does not consider the savings at the intermediate routing nodes in a multi-hop network. A node can route for many other nodes which means the above savings accumulate each time one of its children nodes is reconfigured. Analogous to the above scenario, when routing for 10 such nodes, the routing node would save 10 Joule a day, or 53% of the battery capacity over five years.
5.4Realistic IoT App Analysis
This section analyzes two representative IoT apps, IoT App A and IoT App B, to measure CerberOS in two differ- ent realistic use case scenarios. The IoT App A evaluation focuses on a single IoT app to explicitly compare the char- acteristics of a Java implementation to a C implementation. The IoT App B evaluation focuses on the impact of multi- ple Java apps on a constrained device to explicitly compare a multi-purpose device to a single-purpose device.
5.4.1Single IoT App A analysis
This section compares the execution time, network la- tency and battery lifetime of an IoT device with a single Java IoT app to that of devices with a single C IoT app.  The  app is an example of environment monitoring and combines core IoT functions. It receives temperature requests from a gateway, senses the temperature, encrypts the value, stores it in memory, reads it from memory and replies to the request with the value. The node sleeps between requests. We im- plemented the app in Java and C and deployed it alone on
the same hardware as before in a single-hop mesh network. The code size and deployment cost are analyzed in Section
5.3. Here we consider the execution time and its effect on response latency and battery life time.
The time between request arrival and response transmis- sion is 0.243s for the C app and 0.659s for the Java app, an overhead of 2.712x. Response latency is higher due to the longer processing. However, this cost is small relative to the total round-trip time of the request. Due to the variable na- ture of mesh networks, this time is not deterministic. Even in our single-hop network it varies between 0.5s and 2.5s. As the added time for the Java version is smaller than the la- tency variability, we consider CerberOS feasible in terms of network latency.
Battery lifetime depends on the sampling frequency of the gateway, which determines the duty cycle and the av- erage current. Analysis reveals that the µPnP board con- sumes around 10µA in sleep and 3.5mA while awake, for which we use worst-case figures. The average power con- sumed by the accompanying SmartMesh IP board is 40.5µA, determined through the ‘SmartMesh Power and Performance Estimator’2 as used in [28]. Accordingly, consumed power during sleep is 50.5µA and while awake is 3.54mA. From these figures, we determine the battery lifetime in function of how often the device is sampled. Figure 4 charts the life- time of a node with a 3000mAh battery in terms of a loga- rithmic sampling rate expressed in seconds. The impact of CerberOS is highest for fast sampling rates, halving the life- time for sampling rates faster than once every 10 seconds. Beyond this point the impact decreases rapidly, as the node is sleeping longer. For a 100-second sample rate, the rela- tive reduction is 20%, for a 4-minute rate, 10%, and for a 15-minute rate, 3%. Slower sampling quickly leads to a low energy impact which becomes negligible for sampling rates above hours. Even for fast sample rates, CerberOS achieves multi-month lifetimes and does not exceed more than a 60% reduction compared to a native implementation.
5.4.2Multiple IoT App B analysis
This section analyzes the impact of running multiple apps on a single device in terms of performance and battery life- time. Ideally, the impact scales linearly with the amount of apps. In practice, there is additional overhead due to schedul- ing and app management. We test CerberOS with the same Java IoT app deployed one, three, five and seven times. The Java apps are compared against the ideal case where addi- tional apps require no extra overhead. We do not compare against multiple C apps since concurrent apps in Contiki are not usable in realistic use cases, due to the lack of preemptive multi-threading and as discussed in Section 2.2, and because the ideal case is a stronger comparison. We do analyze the battery lifetime of a single-purpose device with a single C app. The performance and lifetime of a single-purpose C app device compared to a multi-purpose Java app device is the basic economic argument for sharing IoT devices with CerberOS.
IoT App B is, similar to the one in the previous section, representative of real use case IoT apps. It senses the hu-
2Available on: http://www.linear.com/docs/42452.

6.670
6.770
6.780
6.7

5.807
6.751
6.778
6.78
6.486

4.66
0

2.53 1
0.38
1
oT App
in
C


0.
146 1.22 1 oT App in Java

Figure 4. Battery lifetime in years for node sampling rates in seconds with IoT app A.
Table 7. Execution times of a C app and Java apps in seconds and the overhead compared to linear scaling.
#Apps Tot. Exec. timeOverhead to Linear Scaling 1 C App 0.101sN/A | N/A
1 Java App 0.477s0.000s |  0%
3 Java Apps 1.560s0.128s |  9%
5 Java Apps 2.637s0.250s | 10%
7 Java Apps 3.716s0.374s | 11%
midity every user-specified period, encrypts the value, stores and reads it, does I/O to a local screen and sends the value to the gateway. Here we consider the increase in execution time and its effect on the battery lifetime as more apps are deployed and the sampling rate is increased.
Table 7 shows the total execution time for all the apps to run consecutively and the absolute and relative difference of that time compared to the time of a single app linearly scaled to the total amount of apps. A single Java app requires 0.477s to run to completion while the C app requires 0.101s for this case. Scheduling, context switching and managing three, five or seven Java apps causes additional overhead beyond linear scaling which is adding the extra app execution times. The relative size of the overhead increases as more apps are added since scheduling and managing more apps takes longer. For the worst-case seven app scenario, this overhead can be up to 0.374s. The increase in overhead is reasonable when com- pared to linear scaling and varies between 9% for the three app case to 11% for the seven app.
Important is the feasibility of running multiple apps on a constrained device when compared to a single-purpose de- vice. Figure 7 shows how multiple apps compare in terms of battery lifetime and sampling rate to a device with a single C app. For this, we reuse the same energy figures as in Sec- tion 5.4.1. As before, battery lifetime largely depends on the sample rate. For a 10-second sample rate, the C app allows for a 4-year battery lifetime, the single Java app still man- ages a 1.58-year lifetime but the seven Java app case reduces lifetime to 3 months which is a 16x reduction in lifetime
Figure 5. Battery lifetime in years for node sampling rates in seconds for multiple apps (IoT app B).
compared to C. However, as before, with slower and more realistic sampling rates, the impact quickly reduces. For a 100-second sample rate, the seven app case reduces lifetime to a third while supporting seven times the amount of apps, in Java. For a 15-min sampling rate, the reduction in lifetime for the seven app case reduces to 20%. For a (multi-)hour sampling rate, the impact becomes negligible (< 5%).
5.4.3Discussion on feasibility
Evaluation shows that CerberOS is possible for multi-app IoT deployments in two different realistic use cases depend- ing on the sampling rate (whether request/reply- or period- based). Common sample rates in the non real-time embed- ded IoT world are in the order of minutes to hours for which the analysis shows that the energy impact of Java apps is fea- sible. Furthermore, the results reveal that, even for multiple apps, battery lifetime is determined mainly by the sampling rate and scheduling, context switching and app management of multiple apps incurs an acceptable increase in execution time overhead. Finally, while the reduction in lifetime for the seven app case for faster sampling rates (< 10-minutes) is significant, the device supports seven apps instead of one which can be a net benefit, depending on the use case. These results prove that a multi-purpose device with CerberOS is feasible compared to single-purpose devices while unlock- ing several benefits such as the use of a high-level language, resource security and secure shareable infrastructure.
5.5 Security Discussion
In this section, we informally discuss that CerberOS meets the threat model as described in Section 2.3. Specifi- cally, we argue that the three identified attacks by a deployed malicious app are impossible on a system that is designed like CerberOS. These attacks are: (i) rendering the device inoperable, (ii) disrupting other apps and (iii) modifying or stealing data from other apps.
Rendering the device inoperable. An app can try to break the device through three broad categories of attack: (i) crashing through execution of nonsensical instructions, for instance, divide-by-zero operations, (ii) by writing into es- sential memory spaces, such as the OS, and (iii) by depleting the battery deliberately. The first attack is prevented since
an app can only execute Java code. This code is interpreted and, if it is nonsensical, the device will not execute it. The second attack is prevented since apps are isolated; they only have access to their own reserved memory space and are pre- vented from accessing other memory, such as where the OS resides. The third attack is prevented since an app can only execute a contractually limited number of operations (e.g., as determined by priority) on the CPU, network, etc. It cannot keep the device busy for longer than the agreed upon con- tract; once it reaches its resource limits it is stopped from executing further.
Disrupting other apps. An app can try to attack another app on the device through two broad categories of attack: (i) breaking the other app by directly overwriting its code, and
(ii) interfering with the other app by blocking or stealing its essential resources, such as hogging the sensors the other app requires. The first attack is impossible, since, as discussed before, concurrent apps are isolated and cannot write to out- side memory. The second attack is prevented since CerberOS ensures resource security. The app cannot permanently block resources so that other apps have no access since its resource usage is tracked by buckets.
Modifying or stealing data from other apps. An app can try to steal or modify data from another app, for instance, by modifying sensor readings or looking at stored app data. This is prevented since apps are isolated from each other, therefore, an app cannot read or write in the address space of another app. Furthermore, an app cannot influence sensor readings since the app is also isolated from the OS and hard- ware board. Thus, an app cannot break the confidentiality or integrity of the data of another app.
6Conclusions and future work
This paper presents CerberOS, the first resource-secure OS for multi-app IoT devices. CerberOS maximizes RoI on IoT deployments by supporting secure shared platforms be- tween multiple parties and stakeholders. CerberOS realizes the vision of secure tiny multi-app embedded nodes by pro- viding not only strong guarantees on the confidentiality and integrity of app data but also guarantees on the provision and use of key resources such as computation, storage, sensors, actuators and energy.
A virtualization layer, mandatory contract specification and resource tracking through monitoring buckets allow for the management and security of coexisting apps with fine- grained resource management. Together, these elements meet the discussed requirements and provide an answer to the threat model. Furthermore, the interpreter enables the use of Java for app development, unlocking high-level language benefits such as increased developer productivity and porta- bility. CerberOS works on IoT nodes as constrained as Class- 1 devices and requires no special hardware or software mod- ules but can be implemented stand-alone or integrate popu- lar IoT OSs such as Contiki. Results show that CerberOS has a comparable memory cost and execution performance to other similar systems while also supporting multiple apps and resource security. In addition, we have demonstrated that app bytecode deployment is more efficient in terms of time, energy and memory savings at the node. Finally, an analysis
of representative IoT apps shows that the energy impact of our system is feasible for real use cases, even when consid- ering multi-app deployments.
Since CerberOS is a fully fledged OS, there are plenty  of interesting opportunities for future work. Primary future work includes expanding the resource contracts and buckets to better handle the heterogeneity in the IoT and implement- ing the ability to handle soft real-time requirements. Also of interest is exploring how the secure resource management scheme can be made more dynamic and incorporate context awareness to further improve resource security, e.g., in the case of outside denial-of-service attacks. Finally, we would like to leverage existing research for high-level languages to unlock more of their benefits on embedded devices. An ex- ample is doing bytecode analysis to help predetermine node and app behavior. To conclude, we are planning to release the source code in the future with the aim to build a commu- nity of app and OS developers around CerberOS.
7Acknowledgments
This research is partially funded by the Research Fund KU Leuven and the imec High Impact Initiative Distributed Trust. The authors thank Dmitry Grinberg for allowing the use and adaptation of uJ, available on http://dmitry.gr.
8References