I Introduction
Today, realtime embedded systems are used in a variety of domains such as automotive, medical devices, avionics and spacecraft and industrial control (e.g., power plants, chemical plants) to name but a few. Many of these systems are safetycritical by nature. That is, any problems that deter from the normal operation of such systems could result in damage to the system and the environment, and even threaten human safety.
Conventionally, realtime systems (RTS) used custom platforms, software and protocols and were normally not linked to the external world. As a result, security was typically not a priority in the design of RTS. However, due to the drive towards remote monitoring and control facilitated by the growth of the Internet and increased connectivity, as well as the rise in the use of commonofftheshelf (COTS) components, these traditional assumptions are increasingly being challenged. This is evident from recent work (e.g., [9, 13]) that showed that it is easy to attack such systems. The work also demonstrated that successful attacks against such systems could lead to problems more serious than just loss of data or availability because of their critical nature. This has spurred work on security of RTS, including both defensive techniques (e.g., [25, 38, 40, 26, 29, 39, 37, 21]) and attacks (e.g., [9, 13]). These attacks for the most part leveraged the lack of authentication in RTS and their communications.
In this paper, we present a novel reconnaissance attack on RTS that exploits their predictable nature to gather system behavior information that can be used to launch other attacks. Reconnaissance is often the first and an important step for many attacks. For example, the attackers in the case of Stuxnet [11] were in the system undetected for months to collect information before launching their attacks. In RTS, any deviation from the expected behavior is suspicious and easier to detect in contrast to general purpose systems; attackers must operate within narrow operational parameters (e.g., stringent timing and resource constraints) if they are to avoid detection. This is particularly true in the case of sidechannel and covertchannel attacks. Often such attacks require precise knowledge
of when the victim task is about to execute for the attacker to achieve high probability of success
[20, 3, 23]. In such a case, the attacker may have the code of the system, but does not know when the tasks are activated (i.e., task offsets are unknown) because the attacker may enter the system sometime after startup. Hence, the ability to accurately reconstruct the behavior of the system – in this context extracting the points in time when one or more tasks of interest (victims) execute, without being detected, would significantly improve the success of such attacks on RTS. In this work we present algorithms to extract^{1}^{1}1We use extract and reconstruct interchangeably in this paper. (and hence, leak) the precise schedule of the system (section III) without perturbing the system behavior (to reduce the risk of detection)^{2}^{2}2A shorter preliminary version of this paper [10] was presented at a workshop, without archived proceedings..Due to their safetycritical nature, RTS are designed with great care and significant engineering effort to operate in a predictable manner. For instance, (a) designers take great care to ensure that the constituent tasks in such systems execute in an expected manner [22], (b) their interrupts are carefully managed[41] and (c) the execution time is analyzed to great degree at compile time and runtime (e.g., [15, 6, 8]). However, as we demonstrate, this predictability can be a double edged sword – it often makes it easier for adversaries to gauge the behavior of the system with high precision. This can increase the success rates for certain attacks, e.g., sidechannel[20] and covertchannel attacks[35]. An example that demonstrates a cachebased sidechannel attack, leveraging this predictable nature, is presented in section IIC.
Our focus here is on hard realtime systems designed around fixed priority algorithms[7, 22] since these are the most common class of realtime scheduling algorithms found in practice today[24]. Also, this class of scheduling algorithms is most vulnerable to attacks since they are very predictable. We carry out exhaustive simulations to understand the design space for the proposed algorithms (section IVB). Furthermore, we demonstrate an actual implementation of the attack on a hardware board (section IVC) running a realtime operating system.
In summary, the main contributions of this paper are:

a reconnaissance attack scheme aimed at extracting the schedule of fixedpriority, preemptive hard realtime systems – this involves development of algorithms capable of reconstructing the schedule of the system (section III);

introducing new performance metrics for the precision of the schedule inference (section IVA) and evaluating the attack scheme using exhaustive simulations (section IVB);

implementing the attack scheme using a realistic embedded platform (section IVC);

demonstrating one use case where a reconstructed schedule is used to launch other attacks, e.g., a cachebased sidechannel attack (section IVC4).
Ii System and Attack Model
In this section we first introduce the realtime system model used in this paper. Next, we discuss the attack model and the information needed for successfully launching the proposed attack. A demonstrative system and attack scenarios are given in the end. For ease of reference, the notation defined for the ScheduLeak algorithms is summarized in Table I.
Symbol  Definition 
busy interval set  
a busy interval  
start time and length of  
a job set enclosed in  
a subset of consisting of jobs of  
the job in  
arrival time and start time of  
ScheduLeak where  
an arrival window inferred by (defined in section III3) 
Iia Realtime System and Schedule Model
In this paper, a fixedpriority, preemptive hard realtime system is considered. Such a system contains a task set consisting of periodic realtime tasks with hard deadlines. Each task , , is characterized by (period), (worst case execution time), (actual execution time)^{3}^{3}3We assume that the actual execution time at run time is , where represents the variation (which includes jitters) at the job. However, for simplicity, we will use without variation to illustrate the proposed algorithm in section III. , (deadline), (initial arrival time, known as task offset) and (priority) based on [22]. We model the schedule of a periodic realtime system within one hyperperiod as a set of intervals that consists of two subsets: (i) a subset of busy intervals where tasks are under execution [5] and (ii) a subset of idle intervals where there is no task being executed. Specifically, the busy interval set containing busy intervals is defined as . Each busy interval , , is characterized by a tuple , in which and are the start time and the length of , and denotes the job set (instances of tasks) comprising . We further define the notation to be the subset of for in , thus . The job in is then denoted by , that is defined by where is the arrival time when the job is being scheduled and is the start time when the job begins to execute. is greater than or equal to when has to wait for higherpriority tasks executing before it to finish.
IiB Attack and Adversary Model
The goal of the adversary in our model is to steal information while remaining undetected rather than to disable or disrupt the realtime system. Therefore, reconnaissance to obtain knowledge about the system’s operation becomes even more important than in enterprise settings as attack attempts or unsuccessful attacks can more easily be detected due to the deterministic and predictable nature of the system.
We assume that the adversary has a foothold on the realtime system (the attacker is able to run one or more tasks in the system) and has knowledge of the system task set . For example, in a multivendor development model [29]
, an attacker may obtain task set information offline by compromising one of the vendors with weak defenses. Similarly, execution time distributions, that provide the execution times (and estimated variations), obtained during WCET analysis – an essential process in developing a realtime system
[15, 6, 8] may also be obtained offline. A demonstrative avionics system that exemplifies this model along with an attack scenario are introduced in section IIC. These assumptions are not unreasonable as demonstrated by Stuxnet [11], a multistage attack in which the attackers compromised many other systems before reaching their target system, and in which the attackers stayed undetected for months conducting reconnaissance on the target system before they launched their attacks.However, we also assume that the adversary has no knowledge of the initial arrival time for each task. Since initial arrival times of tasks are subject to the system’s operating condition, and the adversary’s attack code might have started sometime after system starts, the values of are unknown a priori to the adversary. Adversary’s goal is to use the known data (i.e., task sets) to learn the system’s runtime behavior and operations without being detected. Specifically, our focus will be on reconstructing the system’s task schedule. This information can be used to increase the success rate of other attacks as exemplified by the sidechannel attack discussed in section IIC.
Observer Task: In preemptive RTS, low priority tasks are particularly useful in monitoring the system’s behavior, e.g., for measuring the execution time of the task that preempts it. Thus, the lowest priority task has the ability to monitor the schedule of a system by observing its busy intervals . We define such a task as the “observer task”. In this paper, we assume that an adversary can gain access to an observer task (i) either by utilizing an existing lowest priority task or (ii) by inserting a new task with the lowest priority and infinite period (hence being continuously active). Note the observed intervals are actually a composite of multiple tasks thus making it difficult for direct use without further analysis. Hence, an algorithm to extract from is required.
IiC Demonstrative System and Attack
Avionics Demonstrator: To motivate our research, we use an example of the Electronic Control Unit (ECU) for an avionics system as depicted in Figure 1. This system runs many of the same types of tasks that could be expected in an Unmanned Aerial Vehicle (UAV) surveillance system [29, 30]. The ECU communicates locally with the inertial sensors, GPS system and actuators (“UAV” in the figure), as well as a camera subsystem. The ECU also uses offboard communication to exchange information with a base station. We assume that three parties are involved in building the ECU system: Vendor 1, Vendor 2 and the Integrator. Each party is responsible for a different ECU subsystem and realtime tasks (See Figure 1).
Targeted Attacks: An attacker who accomplishes the reconstruction of task schedule is able to pinpoint the arrival instant and the start instant of any task on a victim system. Here we introduce an attack that spies upon execution behavior of the target task with the knowledge of the precise task schedule.
Vendor 2 who manages sensor readings has access to the UAV coordinates. This vendor, as an adversary, would like to identify the exact locations of highinterest targets where the surveillance camera is enabled. The attacker can achieve that by learning the behavior (e.g., memory usage, execution modes) of the Encoder Task. For instance, he can launch a storagechannelbased timing attack to observe the resource usage of the Encoder Task and learn whether the task is processing a large amount of data. This attack requires precise knowledge of system operation as a careless attack can result in (i) increased noise and less precision in results, or worse (ii) a realtime task missing its deadline and thus lead to detection. In this paper, we implement a cachebased sidechannel attack on a hardware board to demonstrate the importance and usability of the task schedule inference (See section IVC4).
Iii ScheduLeak
To effectively extract the system’s task schedule, we propose “ScheduLeak”, a novel algorithm that uses the predictable, periodic, nature of hard realtime systems to reconstruct the schedule. It can be represented as a function , where , ScheduLeak algorithm, takes the target system’s task set and busy interval set as inputs and produces the inferred job set . Here, the task set is known except for the arrival time attribute and the busy interval set is obtained from the observer task controlled by the attacker while the details of job set stay unknown. Finally, allows the attacker to pinpoint the possible start time of any particular victim task. The sequence of iterative steps in ScheduLeak are summarized in Figure 2. A detailed illustration is given next.
Iii1 Capturing Busy Intervals
Recall from section IIB that the adversary utilizes his observer task to capture busy intervals. To do so, the observer task checks whether it has been preempted. When a preemption is detected, a busy interval is found. The duration between preemptions is and the start time of this busy interval is . The detailed mechanism for capturing a busy interval is presented in section IVC2. This process of capturing one busy interval repeats until the observer task collects all busy intervals in one hyperperiod (since the schedule of arrivals repeats every hyperperiod). Eventually, the adversary can get the complete busy interval set . Note that ScheduLeak can also work with busy intervals observed from fewer or more than one hyperperiod as discussed in section IVB2
Iii2 Decomposing Busy Intervals
The goal of this step is to estimate possible job compositions of in each busy interval . The duration of can be calculated by
(1) 
where and are known to the adversary. Therefore, the problem here can be further refined as finding the number of jobs for each task arriving in .
A task may either contribute nothing or contribute one or more jobs to , i.e., . But, given the duration of the busy interval, the number of jobs for a task depends on its period and execution time . Therefore, knowing and of every task, we can reduce the number of possibilities for the combination of . We use Theorem 1 described below to either estimate the exact value of or, in the worst case, reduce the possible candidates for to only 2 values.
Theorem 1.
For the task , given values of :
(i) If satisfies
,
then can only contain jobs for .
(ii) If satisfies , then can only contain or jobs for .
We will use the following two lemmas to prove Theorem 1. Consider , , , as the arrival times of task and define .
Lemma 1.
A busy interval contains the job of if and only if it contains .
Proof.
The job of will be released at time if there are no higher priority tasks running at that time, or, will be released immediately after the end of the higher priority tasks. In both cases, the system is busy from time to at least the finishing time of the job of . Therefore, a busy interval which contains has the job of , and a busy interval that contains the job of , should have started at or at a time before . (Note that the end point of a busy interval cannot belong to ).
Lemma 2.
If satisfies , then task can only have arrived or times during the busy interval .
Proof.
If , then contains or points of . Therefore, by Lemma 1, task can only arrive or times during the busy interval .
Proof of Theorem 1.
(i) If , then the busy interval cannot contain points from , otherwise, task should have finished in a time interval less than . Therefore, it exactly contains points from .
If , the start point of the busy interval cannot belong to (otherwise, the should be at least ), therefore, it exactly contains points from .
Therefore, by Lemma 1, in both cases, task can only have arrived times during the busy interval.
(ii) This part follows from Lemma 2 immediately.
Note that Theorem 1 presented here does not take execution time variation in into account for ease of exposition. Nevertheless, the theorem can be easily extended to cover variation by adding tolerance bounds for each variable. Further, our evaluation (section IV) takes execution time variation into account.
Based on Theorem 1, each task , in worst case, may have two candidate values for a busy interval: and . Therefore, computing the right term in Equation (1) with all possible values, there will be at most combinations. Nonetheless, only those combinations that yield exactly and satisfy Equation (1) are shortlisted for further consideration.
Example 1.
Consider a task set and 4 captured busy intervals in a hyperperiod, i.e., , as follows:
5  1  
6  2  
10  2 
Timestamp  
8  [0,8]  
6  [10,16]  
5  [18,23]  
3  [24,27] 
Taking busy interval as an example, by applying Theorem 1 to , we can compute , and values presented in the left table below. And then we use Equation (1) to find possible combinations that can lead to the given busy interval duration as shown in the table to the right in the following. As a result, most combinations are eliminated except the two, and , that can lead to a busy interval length of . In this case, both inferences will be retained for further processing.
0 or 1  
0 or 1  
0 or 1 
0  0  0  0  
0  0  1  2  
0  1  0  2  
0  1  1  4  
1  0  0  1  
1  0  1  3  
1  1  0  3  
1  1  1  5  
desired 
Iii3 Inferring Task Arrival Windows
Here, we estimate possible arrival times for each task. Rather than directly inferring a point for the arrival time , we compute a possible window for that arrival, that we call arrival window, defined as . It is done by computing each job’s arrival window, defined as , in every busy interval and merging the results in the end for each task.
To identify potential arrival windows for in , we partition the busy interval into the following three types of segments for each task :
0interval:  There is no arrival.  
1interval:  There exists exactly 1 arrival.  
01interval:  There may exist 0 or 1 arrivals. 
The partitioning of the busy interval is done using the following theorem.
Theorem 2.
Considering a task and a busy interval that has start time and end time . The partitioning of the busy interval is done by using the following equations:
(i) If has arrived exactly times:
If , the following segments are 1interval:
(2) 
Else, the following segments are 1interval:
(3) 
(ii) If has potentially arrived either or times:
the following segments are 1interval:
(4) 
and the following segments are 01interval:
(5) 
where is the arrival window for in . In both cases, the remainder of the busy interval is 0interval.
Proof.
(i) From Theorem 1, If , then
.
We partition the busy interval as follows:
.
If , or equivalently, , then and there should be an arrival in each interval of the partition above. Also, there cannot be an arrival in , otherwise, the busy interval cannot terminate at . Therefore, there should be an arrival in .
By the periodicity assumption, task arrives every seconds, i.e., if we have an arrival at time , then, is also arrival times. So, shifting by integer multiples of to the left and taking its intersection with other intervals of the partition, we get Equation (2).
If , then and there should not be any arrivals in the last interval of the partition above. Hence, because of the periodicity, the last arrival should be in the interval .
But, if there is an arrival in interval , then there should be an arrival in the interval . Therefore, the busy interval cannot start at . This implies that the last arrival should be in the interval .
Finally, because of the periodicity, by shifting by integer multiples of to the left and taking its intersection with other intervals of the partition, we get Equation (3).
(ii) Using Theorem 1 again, if , then
.
Therefore, in the partition, , and we cannot say anything about the last interval of the partition. So, we mark it as a 01interval, with the consideration that similar to part (i), there cannot be an arrival in . This gives us Equation (5). Also, there should be an arrival in all other intervals of the partition, with the consideration that similar to part (i), there cannot be an arrival in , for . This gives us Equation (4).
Figure 3 shows the use of Theorem 2. Part (a) depicts a case in which and , for . Note that 1intervals for in a busy interval should be repeated every . Part (b) depicts a case in which or and we are not able to determine whether the last interval contains an arrival; hence, it will be a 01interval.
We then use the above segments to find the initial arrival window for . Because of periodicity, a task must arrive exactly once in each time interval of length equal to its period. Moreover, without considering jitters, the relative arrival time in each period should be consistent. Thus, if we divide one hyperperiod into intervals of length and overlap them together, we can obtain a distribution of possible arrival locations of in its period . Here, we take the overlapped segments that have the highest occurrence probability as the arrival window . We will use the following example to demonstrate how this works.
Example 2.
Here we consider task from Example 1 to demonstrate how the arrival window is derived. By following Theorem 2, four busy intervals can be partitioned into segments as shown in Figure 4(a), and the corresponding overlaps are plotted in Figure 4(b). In this case, there are two segments that have the highest overlap count, 3, that represent two possible arrival windows or for task . Similarly, arrival windows for and can be computed as and , respectively. Figure 4(c) shows the arrival window for .
Iii4 Eliminating Ambiguous Estimates
As illustrated in Figure 4(b), the ambiguity in arrival windows is caused by 01interval segments in each arrival window. In such a case, if one of the 01interval segments can be confirmed as 1interval, then we know the correct arrival window. Since the estimation of arrival windows relies on 1interval and 01interval segments that are computed based on – some of which may have ambiguous or values, the solution is to eliminate the ambiguity in . This can be done by applying the arrival window to each busy interval to validate the estimated values. Figure 5 illustrates the process of removing mismatched from a busy interval with ambiguous values by applying inferred arrival windows . The arrival window of in is obtained using:
(6) 
where and are the beginning and the end time points of the initial arrival window . Figure 5 considers the simple case where the arrival window is a continuous interval (shown by the black rectangle). That is, the results of the previous step involving the computation of a distribution are the black rectangles – as expected, they repeat every seconds. Part (a) of this figure shows the case where the arrival window overlaps with a 01interval. This implies that the 01interval is in fact a 1interval. Therefore, the inference becomes . Part (b) shows the case that the arrival window does not overlap with a 01interval – it implies that the 01interval is in fact a 0interval leaving as the only possibility.
By removing mismatched values, the number of possible task combinations for that interval is reduced, sometimes to a unique combination. This reduced set of possible values is then used to update the arrival windows iteratively until the values are stabilized (see Figure 2).
Example 3.
Consider busy interval that has two possible task composition inferences for in Example 1: and . By applying to as shown in Figure 4(d), we confirm that should have arrived one time. This validates the inference of and eliminates . Once the ambiguity in is removed, the only 01interval for inferring in Example 2 can be identified as 0interval based on the correct inference . This leaves the interval on the left in Figure 4(b) as the only correct arrival window for .
Iii5 Reconstructing Schedules
The final step is to generate the start time of each job to reconstruct the schedule. We do this by feeding along with inferred arrival times into a compact scheduling translator (to be explained below). However, at the end of the previously discussed refinement loop, some tasks may still end up with a wider arrival window that cannot be narrowed further. To use a compact scheduling translator, an exact point for each arrival is needed. We propose the beginning point of the first arrival window as the exact arrival time for such tasks. The reasons are: (i) to make sure that jobs in a busy interval do not become disconnected and (ii) since this choice indicates the earliest possible arrival time of a job, attacks launched using this arrival time will never miss the job. Once each arrival time is determined, the compact scheduling translator is ready to reconstruct the schedule. For a selected busy interval , the translator first calculates for every involved job by using adapted from Equation (6). Then, these values can be interpreted as a prearranged arrival queue where the scheduling translator only processes the given jobs. The output of this process is the start time of each job within the busy interval .
Figure 6 presents an example of schedule reconstruction of busy interval in the presence of and where , and . Part (a) shows the arrival times of each job that are obtained from arrival windows and (b) presents the start times output from the scheduling translator. By repeating this process for all busy intervals, the full schedule can be reconstructed.
Iv Evaluation
The ScheduLeak algorithm has been implemented in a simulation platform as well as on a hardware board running a realtime operating system. The simulator is used to explore a larger design space while the implementation on the hardware board demonstrates the feasibility of carrying out such attacks on realistic systems. In this section, we first propose metrics that can be used to evaluate the performance of our algorithms. We then present an evaluation of the algorithm on both simulation engines and hardware board implementation.
Iva Performance Metrics
One way to evaluate the performance of such algorithms is to compare the schedules from the output with that from the ground truth. Let the actual start times for be and the estimated start times be . Let be the error in estimating the start time of the appearance of task . Therefore, for task we have the errors
. We define the standard deviation of these errors from zero as
. We can now define the precision of the estimation of the start time of task as where is the period of task . This value is a number in where indicates an exact estimation of the start times. For a task set containing tasks, we define the overall precision ratio of the algorithm as the arithmetic mean of the estimation precision of tasks in the set, as follows:(7) 
IvB Simulationbased Evaluation
IvB1 Simulation Setup
The ScheduLeak approach was evaluated using both an internally developed scheduling simulation tool and real hardware. The simulation tool was used to test the scalability of the algorithm and also to test with a more diverse set of realtime task combinations.
Task Set Generation: We apply ScheduLeak to randomly generated synthetic task sets and check whether the inference of start times matches the corresponding ground truth. The task sets are grouped by utilization from where . For example, the group contains the task sets that occupy to of CPU utilization. Each utilization group consists of subgroups that have a fixed number of tasks from to respectively. Each subgroup contains task sets. In other words, task sets are generated in each utilization group resulting in task sets to test for one graph. For ease of comparison, we generate task sets with periods that are computed from the factors selected from . Note that The resulting task set may contain some tasks that are harmonic. Then, the initial arrival time (i.e., task offset) for a task is randomly selected between and the task’s period (i.e., ).
Scheduling Algorithm: We use the commonly used ratemonotonic algorithm [22] to assign the priorities of tasks, i.e., a task with a shorter period is assigned a higher priority. We only pick those task sets that are schedulable by fixedpriority scheduling algorithms.
Execution Time Variation:
We use normal distribution to produce execution time variation. A task set is first generated from the aforementioned task set generator that guarantees schedulability. Then, for a task
, the average execution time is computed by , where is chosen empirically. Next, we fit a normal distribution for the task . We let the mean value be and find the standard deviation with which the cumulative probability is . As a result, such a normal distribution produces variation of which are within . To not violate the schedulability, we adjust the deviated execution time to be WCET if it exceeds WCET.IvB2 Simulation Results
We examine the factors affecting the performance of the ScheduLeak algorithm. We test the algorithm with task sets generated under the criteria introduced in section IVB1 (unless stated otherwise) and evaluate the precision ratio using Equation (7).
Empirical Baseline of Inference Precision: To understand how the precision ratio can reflect the correctness of inferences, we compare the ScheduLeak algorithm with a naive algorithm – the initial arrival times are inferred by choosing random time points. Figure 7 shows that the naive algorithm yields inference precision ratios ranging from to – this means that an inferred start time instant has an error over of the period of the corresponding task when compared to the actual instant. It also implies that an attacker may miss an entire computation interval of the victim task and target the wrong interval. In contrast, when using the ScheduLeak algorithm, the inference precision ratio remains high, leading to an average of in precision ratio. This represents an average deviation of (or less) between an inferred start time and the actual start time.
Impact of Execution Time Variation: To understand the extent to which execution time variation impacts the inference precision of the ScheduLeak algorithm, we carried out simulations without execution time variations. We compare such a case with the condition that involves execution time variations produced by the normal distribution where and introduced in section IVB1 (this is also the configuration used by other simulation experiments presented in this section). We also generate another worse case with and for comparison. The results displayed in Figure 8, suggest that the ScheduLeak algorithm performs better when there is no execution time variation (the red line). It yields precision ratio in of the tested task sets with an overall mean precision ratio of . It’s worth nothing that it does not reach precision ratio for all task sets because some may contain harmonic tasks which make it hard to distinguish them when reconstructing. Since having constant execution times is the best case for ScheduLeak, we consider this graph an empirical upper bound of the inference precision ratio when a full hyperperiod is observed. Additionally, the figure shows that larger variation leads to lower inference performance. Nevertheless, it also suggests that the ScheduLeak algorithm can tolerate wide variations. It yields an average precision ratio of in while it is in .
Utilization  Mean  SD  Min  Median  Max 
[0.0,0.1]  0.9211  0.0517  0.6846  0.9210  1 
[0.1,0.2]  0.9275  0.0498  0.7403  0.9285  1 
[0.2,0.3]  0.9290  0.0538  0.7772  0.9289  1 
[0.3,0.4]  0.9407  0.0557  0.7499  0.9466  0.9999 
[0.4,0.5]  0.9555  0.0495  0.8047  0.9692  0.9999 
[0.5,0.6]  0.9606  0.0483  0.7281  0.9832  0.9998 
[0.6,0.7]  0.9665  0.0447  0.7576  0.9977  0.9997 
[0.7,0.8]  0.9728  0.0405  0.7386  0.9975  0.9996 
[0.8,0.9]  0.9737  0.0379  0.8008  0.9968  0.9993 
[0.9,1.0]  0.9722  0.0398  0.8005  0.9958  0.9991 
Impact of Task Set Utilization: Next, we analyze how the utilization of the realtime task sets can affect the precision of our analysis. The precision ratios for each utilization group are plotted in Figure 8 (the blue line). Raw precision ratios for each task set are provided in Figure 9, and the statistical data is summarized in Table II. From the figures, we observe that the precision ratio decreases as the utilization decreases. It is because lower utilizations may indicate (i) potentially shorter execution times and (ii) smaller and scattered busy intervals – both of which are detrimental to our analyses. If a task’s execution time is smaller than any other task’s variation, it can cause the algorithm to falsely filter out such a short task when decomposing a busy interval, resulting in inaccurate inferences. Further, small and scattered busy intervals reduce the probability that an inferred arrival time can successfully land within the busy interval. Under such circumstances, ScheduLeak can’t resolve certain inferences.This false negative is due to the fact that the algorithm only considers the beginning point of an inferred arrival window when reconstructing the schedule of a busy interval (as stated in section III5). This ambiguity influences the inference precision the most when the busy interval is short.
Furthermore, from the zoomed diagram in Figure 9 and Table II we also observe that the maximum and median precision ratios decrease slightly at high utilizations. It is because higher utilizations lead to larger busy intervals. Consequently more ambiguous conditions show up while trying to estimate the number of arrivals in a busy interval, making it difficult for the ScheduLeak algorithm to arrive at a correct inference.
Impact of the Number of Tasks: Another factor that may affect the precision ratio is the number of tasks in a task set. We compute mean precision ratios for 15 subgroups that have the number of tasks ranging from 1 to 15 and see whether it influences the precision. The result are presented in Figure 10. It shows that the more tasks involved in a system, the harder the ScheduLeak algorithm can correctly infer the schedules. It is because having more tasks in a system means potentially more tasks may be involved in a busy interval. It also implies that there can be more possible combinations for the composition of a busy interval, which increases the difficulty of the analysis from ScheduLeak.
Impact of Observation Duration: In the previous experiments, we fed ScheduLeak with busy intervals observed from a full hyperperiod. However, since busy intervals are analyzed in a discrete fashion in ScheduLeak, it is also possible to process the algorithms with busy intervals observed from fewer or more than a full hyperperiod. To evaluate the impact of observation duration, we let ScheduLeak observe different proportions of the schedule and collect busy intervals within the observation duration. The busy intervals that are not complete at the edge are discarded. The proportion we examine here ranges from to of a hyperperiod. The results are shown in Figure 11. From the figure, we can see that ScheduLeak yields a precision ratio of when observing of a hyperperiod. If we only compute the corresponding precision ratio for the busy intervals within the observation duration, we get a precision ratio of when observing of a hyperperiod. In both cases, the inference precision gets higher as more portions of the schedule are observed. It’s worth mentioning that the inference precision is improved even after collecting over of a hyperperiod. It is due to the nature of normal distributions where the variation around the mean point has high occurrence probability. That is, as more data is sampled, the variation can be neutralized, resulting in the ScheduLeak algorithm’s ability to infer more accurate arrival windows and start points.
IvC Zedboardbased Evaluation
IvC1 Zedboard Setup
We implemented the ScheduLeak algorithm on an ARMbased development board, the Zedboard[2]. The processor runs at and drives a shared bit Global Timer (GT) that is clocked at . We tested our implementation with a variety of different task sets, starting from the UAV model (Figure 1 and section IIC) to many synthetic task sets. The task sets ran on a realtime operating system, FreeRTOS – a lightweight and open source realtime kernel[1]. It is powered by a prioritybased preemptive realtime scheduler. To obtain “ground truth”, the FreeRTOS kernel has been modified to record time stamps for context switches.
IvC2 Implementation
We introduce how the observer task captures busy intervals as this step is hardwaredependent. The Global Timer (GT) that is accessible to user tasks in FreeRTOS is used as a time reference to capture busy intervals. As mentioned above, GT is clocked at , hence its resolution can be computed as . To capture a busy interval, the observer task uses GT as a reference to inspect whether or not it has been preempted. The observer task reads GT in a loop and compares it with the time stored from last read. If nothing preempts the observer task during the loop, then the difference for times between consecutive loops remains below one unit of the loop execution time (time measurement is presented in section IVC3). In contrast, if the difference is greater than expected, then a preemption must have occurred. The observer task repeats the same process until it collects all busy intervals for at least one hyperperiod. After that, the program moves to the busy interval analysis stage. The granularity of the observer task measurements is further discussed in the next part.
IvC3 Zedboardbased Results
Observer Task Overhead: We first examine the execution cost of the observer task and its impact on the ability to capture busy intervals. Our observer task uses a loop to read time values from the Global Timer. The shortest busy interval that can be measured depends on the cost of reading the timer and executing the observer task instructions. The cost of each read loop measures , on average, in the absence of preemption. This is really small compared to the execution times of realtime tasks which are typically more than . The Global Timer counts times during each read loop. On the other hand, a small busy interval with just one task that has execution time of will result in the counter incrementing times. Hence, it is very unlikely that the observer task will miss any busy intervals.
The actual cost for capturing a busy interval varies since the timing now involves a pair of context switches. From our experiments a pair of context switches takes on average on this board. This adds to the length of any busy interval but the costs are bounded as each measurement only includes two read loops. We can confidently remove these costs from every busy interval. This leaves only jitters as a source of uncertainty in our measurements. From our experiments, removing the observer task costs results in a error, on average, for each busy interval. If the delta due to this error is greater than the execution time for the shortest task then it introduces uncertainty into our analysis since we cannot separate it from a legitimate task. In practice, this depends on the actual application. For the UAV model presented earlier on, the shortest task (the Network Manager) has an execution time of – two orders of magnitude higher than the error/delta. Hence, the errors in measuring the busy intervals did not really impact our analyses.
Onboard Analysis Overhead: It is important to note that the analysis of busy intervals need not necessarily be performed online. For some attack scenarios, the data can be analyzed offline. Hence, the analysis will not be limited by the performance of the hardware. In this section though, we focus on the overheads for carrying out the analysis on the actual board to demonstrate the feasibility of online analysis.
The estimate of uses Equation (1) to find the matching combinations for a busy interval. This has order of time complexity. However, the number of tasks is often fixed for a task set, thus is bounded in a given realtime system. On Zedboard, a task task set costs in the worst case to process all possible combinations for a busy interval. Calculating arrival windows depends on the number of job instances of each task in a hyperperiod. From our experiments on average, it takes to calculate arrival windows for the task task set mentioned above where each task executes for around . For the elimination of mismatched values it takes arrival windows of tasks to inspect each estimate in every busy interval. This has a complexity in the order of . In the same experiment as above, it takes to iterate through busy intervals with arrival windows from the correspondent tasks. Finally, for a task set with tasks that have busy intervals on our Zedboard, it takes to complete the total analysis. In this test case, ScheduLeak yields a precision ratio of .
IvC4 Implications of ScheduLeak
We now demonstrate an attack that takes advantage of the task schedule information obtained using ScheduLeak by implementing the attack case introduced in section IIC. In particular we use a cachebased sidechannel attack [19, 27, 28] (as an instance of storagechannelbased timing attacks) to precisely gauge the cache usage of a victim task, in this case the image encoder task. The cachebased sidechannel attack is launched from a periodic task that has the highest priority (as opposed to the observer task that uses the lowest priority). With the schedule information, we carefully place the cache prime and probe steps [27] before and after the image encoder task begins and ends. We let the attacker task halt the attack if we know that the victim task will not appear in the next period. Figure 12(a) displays the result of this attack. It shows that the cachebased sidechannel attack with schedule information can effectively filter out unnecessary information and preserve the cache usage behavior of the victim task. On the other hand, Figure 12(b) demonstrates the case where the attacker has no knowledge of the task schedule. The attacker then has to launch the cachebased sidechannel attack in every period randomly. As a result, the obtained cache usage contains too much noise from other tasks, making it difficult to obtain useful information.
V Discussion
We evaluated the algorithm by varying four variables: (i) execution time variation, (ii) CPU utilization, (iii) the number of tasks (iv) observed duration. From the results, we can conclude that the following factors may influence the inference precision: Execution Time Variation: Large execution time variation can reduce the precision of the inference. As shown in Figure 8, the ScheduLeak algorithms yield an average precision ratio of and in and respectively. The Number of Tasks: Having more tasks in a system means more possible combinations in decomposing a busy interval. The precision ratio decreases as the number of tasks increases, as shown in Figure 10. Busy Interval Length: A short busy interval reduces the probability that an inferred arrival time can successfully land within the busy interval. This mostly happens when the task set utilization is low, which decreases the inference precision. Task Set Utilization: Higher utilization represents larger busy intervals and more tasks involved in one individual busy interval, leading to increased uncertainty. This results in a decrease of overall inference precision. Observed Duration: The ScheduLeak algorithms can work with capturing just a portion of the task schedule. Accumulating more busy interval observation can improve the inference precision. This is also true when more than one hyperperiod is observed.
Vi Related Work
Recent work on RTS security has demonstrated the feasibility of information leakage via scheduling. Son et al. [32] highlighted the susceptibility of RM schedulers to covert timing channel attacks. Völp et al. [35] presented modifications to fixedpriority scheduling, altering thread blocks that potentially leak information with the idle thread to avoid the exploitation of timing channels. Völp et al. [34] examined sharedresource covert channels in realtime schedules and addressed it by modifying resource locking protocols.
Kadloor et al. [18] introduces a methodology for quantifying sidechannel leakage for firstcomefirstserve and timedivisionmultipleaccess schedulers. Gong and Kiyavash [14] analyzed deterministic workconserving schedulers. They discovered a lower bound for the total information leakage. The collaborative version of this problem where two users form a covert channel in a shared scheduler to steal private information from a secure system is studied by Ghassami et al. [12]. While in these works the attacker uses traffic analysis to obtain information about the user activities, our work is primarily concerned with reconstructing the original task schedule as a stepping to stone to other stealthy attacks.
Mohan et al. [26] considered the problem of direct information leakage between realtime tasks through architectural resources such as shared cache. They introduced a modified fixedpriority scheduling algorithm that integrates security levels into scheduling decisions. Pellizzoni et al. [29] extended the above scheme to a more general task model and also proposed an optimal priority assignment method that determines the task preemptibility.
Cachebased sidechannels contain the highest bandwidth among all sidechannels, making them invaluable for information leakage [19, 27, 28]. The growth of cloud computing has caused such attacks face increased scrutiny (e.g., [16, 31]). Wang and Lee [36] presented a hardened cache model to mitigate sidechannels by adopting partitioning and memorytocache mapping randomization techniques. However, most existing methods aimed at reducing leakage through cachebased sidechannels have not considered realtime systems. While other methods of sidechannel attacks exist such as power, electromagnetic and frequency analysis [33, 4, 17], they are not the focus of this paper.
Vii Conclusion
The methods presented here will improve the design of future realtime systems. Designers will have an increased awareness of attack mechanisms that leak crucial information in such systems. Hence, they can develop methods that prevent or at least reduce the effectiveness of such attacks.
We intend to further refine the algorithms presented here and also develop solutions to deter such attacks. We believe that the area of security for realtime systems will require the development of a large body of work, along multiple directions, to ensure the overall safety of such systems.
References
 [1] FreeRTOS. http://www.freertos.org/.
 [2] Xilinx Zedboard. http://zedboard.org/.
 [3] Aciiçmez, O., Koç, c.K. and Seifert, J.P. On the power of simple branch prediction analysis. In Proceedings of the 2nd ACMCCS, 2007.
 [4] Agrawal, D. et al. The em sidechannel(s). In the 4th International Workshop on Cryptographic Hardware and Embedded Systems, 2003.
 [5] Baker, T.P. An analysis of edf schedulability on a multiprocessor. IEEE Transactions on Parallel and Distributed Systems, 16(8):760–768, 2005.
 [6] Burns, A. and Edgar, S. Predicting computation time for advanced processor architectures. In RealTime Systems, 2000. Euromicro RTS 2000. 12th Euromicro Conference on, pages 89–96. IEEE, 2000.
 [7] Buttazzo, G.C. Hard RealTime Computing Systems: Predictable Scheduling Algorithms and Applications. 1997.
 [8] Cazorla, F.J. et al. Proartis: Probabilistically analyzable realtime systems. ACM Transactions on Embedded Computing Systems, 2013.
 [9] Checkoway, S. et al. Comprehensive experimental analyses of automotive attack surfaces. In USENIX Security Symposium, 2011.
 [10] Chen, C.Y. et al. Scheduleak: An algorithm for reconstructing task schedules in fixedpriority hard realtime systems. In 1st Workshop on Security and Dependability of CERTS, 2016.
 [11] Chen, T.M. and AbuNimeh, S. Lessons from stuxnet. Computer, 44(4):91–93, 2011.
 [12] Ghassami, A., Gong, X. and Kiyavash, N. Capacity limit of queueing timing channel in shared fcfs schedulers. In 2015 IEEE International Symposium on Information Theory (ISIT).
 [13] Gollakota, S. et al. They can hear your heartbeats: noninvasive security for implantable medical devices. ACM SIGCOMM Computer Communication Review, 41(4):2–13, 2011.
 [14] Gong, X. and Kiyavash, N. Timing side channels in shared queues. CoRR, abs/1403.1276, 2014.
 [15] Hansen, J., Hissam, S.A. and Moreno, G.A. Statisticalbased wcet estimation and validation. In Proceedings of the 9th Intl. Workshop on WorstCase Execution Time (WCET) Analysis, 2009.
 [16] Irazoqui, G. et al. Fine grain crossvm attacks on xen and vmware. In Big Data and Cloud Computing (BdCloud), IEEE, 2014.
 [17] Jiang, K. et al. Robustness analysis of realtime scheduling against differential power analysis attacks. In 2014 IEEE Computer Society Annual Symposium on VLSI (ISVLSI).
 [18] Kadloor, S., Kiyavash, N. and Venkitasubramaniam, P. Mitigating timing side channel in shared schedulers. CoRR, abs/1302.6123, 2013.
 [19] Kelsey, J. et al. Side channel cryptanalysis of product ciphers. In European Symposium on Research in Computer Security, 1998.
 [20] Kocher, P.C. Timing attacks on implementations of diffiehellman, RSA, DSS, and other systems. In Advances in Cryptology  CRYPTO 1996, 16th Annual International Cryptology Conference.
 [21] Lin, M. et al. Static security optimization for realtime systems. IEEE Transactions on Industrial Informatics, 5(1):22–37, Feb 2009.
 [22] Liu, C.L. and Layland, J.W. Scheduling algorithms for multiprogramming in a hard realtime environment. Journal of the ACM, 1973.
 [23] Liu, F. et al. Lastlevel cache sidechannel attacks are practical. In IEEE Symposium on Security and Privacy, pages 605–622, 2015.
 [24] Liu, J.W.S. RealTime Systems. Prentice Hall, 2000.
 [25] Mohan, S. et al. S3A: Secure system simplex architecture for enhanced security and robustness of cyberphysical systems. In ACM Conference on High Confidence Networked Systems, 2013.
 [26] Mohan, S. et al. Realtime systems security through scheduler constraints. In Euromicro Conference on RealTime Systems, 2014.
 [27] Osvik, D.A., Shamir, A. and Tromer, E. Cache attacks and countermeasures: the case of aes. In Cryptographers’ Track at the RSA Conference, pages 1–20. Springer, 2006.
 [28] Page, D. Theoretical use of cache memory as a cryptanalytic sidechannel. IACR Cryptology ePrint Archive, 2002:169, 2002.
 [29] Pellizzoni, R. et al. A generalized model for preventing information leakage in hard realtime systems. In IEEE RealTime Embedded Technology and Applications Symposium, 2015.
 [30] Puri, A. A survey of unmanned aerial vehicles (uav) for traffic surveillance. Dept. of computer science and engineering, University of South Florida, 2005.
 [31] Ristenpart, T. et al. Hey, you, get off of my cloud: exploring information leakage in thirdparty compute clouds. In Proceedings of the 16th ACM conference on Computer and communications security. ACM, 2009.
 [32] Son, J. and AlvesFoss, J. Covert timing channel analysis of rate monotonic realtime scheduling algorithm in mls systems. In IEEE Information Assurance Workshop, 2006.
 [33] Tiu, C.C. A new frequencybased side channel attack for embedded systems. Technical report, 2005.
 [34] Völp, M. et al. On confidentiality preserving realtime locking protocols. In IEEE, RTAS, 2013.
 [35] Völp, M., Hamann, C.J. and Härtig, H. Avoiding timing channels in fixedpriority schedulers. In ACM Symposium on Information, Computer and Communication Security, 2008.
 [36] Wang, Z. and Lee, R.B. New cache designs for thwarting software cachebased side channel attacks. In Proc. of the 34th annual ACM international symposium on Computer architecture, 2007.
 [37] Xie, T. and Qin, X. Improving security for periodic tasks in embedded systems through scheduling. ACM Trans. Embed. Comput. Syst., 2007.
 [38] Yoon, M.K. et al. SecureCore: A multicorebased intrusion detection architecture for realtime embedded systems. In IEEE RealTime Embedded Technology and Applications Symposium, 2013.

[39]
Yoon, M.K. et al.
Memory Heat Map: Anomaly detection in realtime embedded systems using memory behavior.
In Proc. of the ACM Design Automation Conference, 2015.  [40] Zadeh, M.M.Z. et al. SiPTA: Signal processing for tracebased anomaly detection. In Proc. of the International Conference on Embedded Software, 2014.
 [41] Zhang, Y. and West, R. Processaware interrupt scheduling and accounting. In Proc. of the 27th IEEE International RealTime Systems Symposium, 2006.
Comments
There are no comments yet.