1. Introduction
The primary concerns in designing safe critical realtime systems are to develop a methodology to effectively allocate limited computing resources (e.g., memory and CPU (central processing unit)) to multiple realtime tasks (e.g., motor control and sensing), and to derive a mathematical analysis mechanism. This mechanism would ensure every operation conducted by realtime tasks are completed within predefined time units (called deadlines) to satisfy realtime requirements [
1]. The former and latter, which are respectively referred to as realtime scheduling algorithms and schedulability analysis, have been extensively studied over the past several decades in the field of realtime systems [
2,
3,
4].
Unlike conventional research, which mostly focuses on the timing guarantees under various computing environments with different operational constraints, recent studies have focused on the security aspect because the modern realtime systems are exposed to unknown security attacks. For instance, modern realtime systems are increasingly being connected to unsecured networks such as the Internet, which allows the sophisticated adversaries to launch security attacks on UAVs (unmanned aerial vehicles) [
5], industrial control systems [
6], and automobiles [
7,
8].
Predictability, which is a key property of realtime systems, facilitates the development of several effective schedulability analysis mechanisms, but causes an increase in the success ratio of security attacks because of easy timing inferences [
9,
10,
11]. Because most of the realtime tasks are conducted periodically, the execution patterns can be highly predictable, and most of the strong schedulability analysis mechanisms such as deadline analysis (DA) [
12] and responsetime analysis (RTA) [
13] exploit such a property to judge whether each realtime operation can be completed within the deadline on the target environment. Such a seemingly advantageous property plays a doubleedged sword because the security attackers can analyze the predictable execution patterns of realtime systems and use them as attack surfaces. For example, recent studies have shown that an adversary can launch cachebased sidechannel attacks by collecting information about important tasks or set up new covert channels [
9,
14]. The success ratio of such attacks is quite high because the periodic execution of realtime tasks results in repeated (based on the hyperperiod of all realtime tasks on the system) scheduling patterns. After observing the realtime task schedules on the target systems, the adversary can predict future schedules of the system.
The main challenge in preventing such timing inferencebased security attacks on realtime systems is making the initially predictable schedule unpredictable, while simultaneously satisfying the realtime constraint. Among the few proposed mechanisms that have been used to address the problem of the uniprocessor system, TaskShuffler (a schedule randomization protocol) has received considerable attention owing to its simplicity and applicability [
15]. TaskShuffler exploits the notion of priority inversion budget, defined as the time interval between the finishing time of worstcase operation and deadline, of each task. Priority inversion budget value of each task implies that the task can complete its execution even if the other tasks execute for the amount of worstcase inversion budget instead of the task. Utilizing the calculated priority inversion budget value of each task, the TaskShuffler effectively selects random tasks at each schedule point and dynamically manages the value to induce uncertainty and satisfy the realtime constraint simultaneously.
As multiprocessor platforms have been increasingly adopted modern realtime systems to conduct highly resourceconsuming tasks, the stateoftheart techniques need to be tailored for multiprocessor platforms. For example, the latest embedded platforms developed for autonomous driving car consist of multiple CPUs to execute heavyload tasks such as multiple sensing and image processing (e.g., NVIDIA Drive AGX Pegasus with 8core “Carmel" CPUs based on ARM architecture) [
16]. However, the existing TaskShuffler is only applicable to uniprocessor platforms, where the task execution pattern is quite simple to analyze when compared to multiprocessor platforms.
In this study, we propose a new schedule randomization protocol for realtime systems on symmetry multiprocessor platforms where all processors are composed of the same architecture, which extends the existing TaskShuffler initially designed for uniprocessor platforms. To develop a schedule randomization protocol for multiprocessor platforms, we need to address the following issues:
 (i)
How to define the problem of improving the security (i.e., uncertainty of schedules) of realtime systems and satisfying the schedulability simultaneously on multiprocessor platforms, differentiating it from the uniprocessor case (
Section 2),
 (ii)
How to calculate the priority inversion budget value for each task on multiprocessors (
Section 4.1),
 (iii)
How to utilize the calculated priority inversion budget values in randomized schedules effectively, to improve uncertainty (
Section 4.2), and
 (iv)
How to satisfy the realtime requirement after applying the proposed schedule randomization protocol (
Section 4.2).
To address point (i), we first recapitulate the underlying idea and purpose of the existing TaskShuffler designed for the uniprocessor case. Then, we define the problem for the multiprocessor case, which is addressed in this study. To address point (ii), we investigate each task’s surplus computing power allowed for lowerpriority tasks without missing its corresponding deadline. To address point (iii), such lowerbound computing power is effectively utilized by the new schedule randomization protocol proposed in this study. In addition, we demonstrate that if the task set is schedulable with the fixedpriority (FP) preemptive scheduling, then it is schedulable with the proposed schedule randomization protocol; this addresses point (iv). Using experimental simulations, we then discuss various factors affecting the uncertainty of new schedules.
2. Problem Definition
TaskShuffler assumes that the attacker knows task sets’ parameters as well as scheduling policy of the target system [
15]. The attacker aims at gleaning sensitive data such as the victim task’s private key in shared resources such as DRAM (dynamic random access memory).
Figure 1 briefly presents a scenario where the attacker launches a cache sidechannel attack exploiting the scheduling pattern of realtime systems. The attacker first hijacks a task
$tas{k}_{A}$ consecutively executing with a victim task
$tas{k}_{V}$; it assumes that
$tas{k}_{A}$ is relatively easy to hijack compared to
$tas{k}_{V}$ because
$tas{k}_{A}$ is not related to the security operation. Then, the attacker fills all cache sets with
$tas{k}_{A}$’s data before
$tas{k}_{V}$ executes. Thereafter,
$tas{k}_{V}$ operates a cryptographic operation with a private key. Here, all cache sets were already filled with
$tas{k}_{A}$’ data, and thus some cache sets are replaced by
$tas{k}_{V}$’ data. Later,
$tas{k}_{A}$ reads cache sets and measures the latencies. Some cache sets used by
$tas{k}_{V}$ result in slow latencies because of cache misses for
$tas{k}_{A}$. The attacker collects such timing information and reasons the location of the private key in the shared memory.
To make such an attack scenario feasible, the attacker should monitor the execution pattern of the target system for a long time to catch the proper timing to launch the attack. Because the same execution pattern of realtime systems is (mostly) repeated, the success ratio of the attack would increase.
Figure 2 presents the scheduling pattern of
$\tau =\{{\tau}_{0}({T}_{0}=5,{C}_{0}=1,{D}_{0}=5),{\tau}_{1}(8,2,8),{\tau}_{2}(20,3,20)\}$ scheduled by a fixedpriority scheduling (
${\tau}_{0}$ and
${\tau}_{2}$ have the highest and lowest priorities, respectively) without (
Figure 2a) and with (
Figure 2b) TaskShuffler on a uniprocessor platform. It shows which task executes in 200 time slots, and the number in each rectangle presents the task index executed at the time slot. As shown in
Figure 2a, the scheduling pattern is repeated every 40 time units because the least common multiple of periods of tasks in
$\tau $ is 40. On the other hand, the scheduling pattern is obfuscated by TaskShuffler (most importantly) without schedulability loss (
Figure 2b). That is, every task both in
Figure 2a,b completes its execution without any deadline miss. It implies that TaskShuffler could improve potential durability against timinginference attacks by obfuscating the scheduling pattern of realtime systems without schedulability loss.
In this study, we aim to develop a new schedule randomization protocol for multiprocessor platforms by extending the existing TaskShuffler initially designed for uniprocessor platforms. To achieve this, we first recapitulate the underlying idea and purpose of the existing TaskShuffler designed for the uniprocessor case. Then, we define the problem for the multiprocessor case, which is addressed in this study.
The key property of realtime systems is that most of the tasks operate repetitively at periodic intervals. This indicates that the same scheduling pattern for a certain period of time (e.g., one hyperperiod of all tasks) can be exhibited in the next period. Although such property aids in developing betterperforming analysis techniques that can easily judge the schedulability of realtime systems, an adversary can launch timinginference attacks by collecting information about important tasks or set up new covert channels.
The TaskShuffler compensates for such shortcoming of realtime systems by reducing the predictability of schedules for realtime tasks. Therefore, even if an observer can record the exact schedule for a certain time period, the same will not be exhibited in the next period under the TaskShuffler. The underlying idea of the existing TaskShuffler is to pick up a random task from the ready queue, unlike most of the realtime systems where the highest priority task is selected for scheduling. Such counterintuitive mechanisms lead to the priority inversion problem and deadline misses, placing system safety at risk. To solve this problem, the TaskShuffler only allows limited priority inversion for each task. That is, it restricts the use of priority inversion so that every task meets the original realtime constraint (i.e., meeting deadlines). To this end, it calculates the lowerbound amount of priority inversion that each task can tolerate, using the TaskShuffler protocol. When the priority inversion limit is reached during execution, the lowerpriority task stops running, and the highest priority task is selected to be scheduled.
Then, the TaskShuffler achieves the following goal G.
 G.
Suppose that a task set $\tau $ is scheduled by a given FP scheduling algorithm S, and its schedulability is guaranteed by a given schedulability analysis A. Then, $\tau $’s schedulability is still guaranteed by a given schedulability analysis ${A}^{\prime}$ when it is scheduled by the FP algorithm ${S}^{\prime}$ incorporating the TaskShuffler protocol of uniprocessors.
Let
$\lambda \left(S\right)$ be the set of schedulable task sets scheduled by FP scheduling, and
$\lambda \left(A\right)$ be the set of task sets each of whose schedulability is guaranteed by a given schedulability analysis supporting FP scheduling. In addition,
$\lambda {\left(S\right)}^{\prime}$ denotes the set of schedulable task sets scheduled by FP scheduling incorporating TaskShuffler, and
$\lambda \left({A}^{\prime}\right)$ is the set of task sets each of whose schedulability is guaranteed by a given schedulability analysis supporting FP scheduling incorporating TaskShuffler.
Figure 3a shows the regions of task sets covered by
$\lambda \left(S\right)$,
$\lambda \left(A\right)$,
$\lambda \left({S}^{\prime}\right)$, and
$\lambda \left({A}^{\prime}\right)$ for uniprocessor platforms.
$\lambda \left(S\right)=\lambda \left(A\right)$ in
Figure 3a indicates a wellknown fact that every schedulable task set
$\tau \in \lambda \left(S\right)$’s schedulability is guaranteed by the given exact schedulability analysis (e.g., RTA supporting FP scheduling) [
13]. Then, the TaskShuffler targets task sets belonging to
$\lambda \left(A\right)$ (
$=\lambda \left(S\right)$) and applies the TaskShuffler protocol; note that task sets out of
$\lambda \left(A\right)$ has nothing to do with the goal
G. It utilizes a specialized schedulability analysis
${A}^{\prime}$ to support the FP scheduling
${S}^{\prime}$ incorporating the TaskShuffler protocol. When
${A}^{\prime}$ is conducted for each task
${\tau}_{i}\in \tau $, the lowerbound amount of priority inversion for each task is calculated, and the TaskShuffler exploits it without compromising the schedulability of task sets
$\tau \in \lambda \left(A\right)$. Therefore, it achieves
$\lambda \left(S\right)=\lambda \left(A\right)=\lambda \left({A}^{\prime}\right)=\lambda \left({S}^{\prime}\right)$ as shown in
Figure 3a.
For multiprocessor platforms, there is no exact schedulability analysis for our system model [
17], which provides
$\lambda \left(S\right)\ne \lambda \left(A\right)$ as shown in
Figure 3b. Therefore, we target
$\left(\lambda \right(A)\u228a\lambda (S\left)\right)$ in which tasks’ schedulabiliy are guaranteed by the DA schedulability analysis and aim at achieving the goal
G on multiprocessors.
3. System Model
We consider a task set
$\tau $ the Liu and Layland task (and system) model (considered as the defecto standard in the field of realtime scheduling theory) in which every task
${\tau}_{k}\in \tau $ is scheduled by global, preemptive and workconserving FP realtime scheduling algorithm on
m identical multiprocessors [
1]. A scheduling algorithm is called global, preemptive and workconserving if a task migrates from one processor to another, a lowerpriority task is preempted by a higherpriority one, and the processor is never idle when there are jobs to be executed, respectively. In FP scheduling, the priority is assigned to each task such that all jobs invoked by the same task have the same priority. The Liu and Layland model assumes that tasks are independent, no synchronization is needed, and resources (except processors or cores) are always available. According to the task model, we assume that all processors share the common cache and main memory. A task
${\tau}_{k}$ periodically invokes a job
${J}_{k}$ in every
${T}_{k}$ time units, and each job is supposed to execute for at most
${C}_{k}$ time units (also known as the worstcase execution time (WCET) ) to declare its completion. Every job invoked by
${\tau}_{k}$ should complete its execution in
${D}_{k}$ time units as a realtime constraint.
jth job invoked by a task
${\tau}_{k}$ is denoted by
${J}_{k}^{j}$, and it is invoked at the release time
${r}_{k}^{j}$ and should finish its execution within the absolute deadline
${d}_{k}^{j}={r}_{k}^{j}+{D}_{k}$. We use the notation
${J}_{k}$ when it indicates an arbitrary job of a task
${\tau}_{k}$. A job
${J}_{k}$ is said to be schedulable when it finishes its execution before its absolute deadline
${d}_{k}^{j}$. Further, a task
${\tau}_{k}$ is said to be schedulable when all jobs invoked by
${\tau}_{k}$ are schedulable, and a task set
$\tau $ is said to be schedulable when all tasks
${\tau}_{k}\in \tau $ are schedulable.
$lp\left({\tau}_{k}\right)$ and
$hp\left({\tau}_{k}\right)$ represent the set of tasks whose priorities are lower than that of
${\tau}_{k}$ and that whose priorities are higher than that of
${\tau}_{k}$, respectively. We consider
online scheduling algorithms and
offline schedulability analysis (in online scheduling algorithms and offline schedulability analysis, the priorities of pending or executing jobs (i.e., scheduled by the given scheduling algorithm) are determined after the system starts, while the schedulability of the given task set is judged before the system starts.)
4. Schedule Randomization Protocol for Multiprocessors
The key idea of our schedule randomization protocol is to select random jobs from the ready queue rather than the originally prioritized ones that are supposed to be selected by a given algorithm. This operation inevitably causes priority inversions for some tasks, which can induce an additional execution delay when compared to the existing schedule. This can result in a deadline miss in the worst case, even if the task is deemed schedulable by a given schedulability analysis. To avoid such situations, we should employ bounded priority inversions (calculated by the schedule randomization protocol) so that every task completes its execution before its corresponding deadline.
In this section, we first calculate the upper bound of allowed priority inversions for each task (in the first subsection), and then present how to effectively utilize such calculated priority inversions budget values in a schedule randomization protocol for multiprocessors.
4.1. Priority Inversion Budget Calculation
As an offline step of our schedule randomization protocol for multiprocessors, the maximum number of time units that are allowed for jobs of tasks in $lp\left({\tau}_{k}\right)$ to execute when a job of the task ${\tau}_{k}$ waits for another job to complete should be calculated (we use a subscript ‘k’ if the notation is related to a task whose schedulability will be judged. We use a subscript ‘i’ if the notation is related to higher priority tasks of ${\tau}_{k}$.). We refer such time units as the priority inversion budget, ${V}_{k}$, which will be utilized in the online step of randomization protocol. We define the worstcase inversion budget as follows.
Definition 1. (Priority inversion budget ${V}_{k}$) The priority inversion budget ${V}_{k}$ of a task ${\tau}_{k}$ is defined as the maximum amount of time units in [${r}_{k}$, ${d}_{k}$) that is allowed for jobs of tasks in $lp\left({\tau}_{k}\right)$ to execute while a job ${J}_{k}$ of a task ${\tau}_{k}$ waits on multiprocessors, which ensures schedulability of ${\tau}_{k}$.
Thus, ${V}_{k}$ can be lowerbound by calculating the allowable limit for delay in execution of ${J}_{k}$ caused by lowerpriority jobs in $[{r}_{k},{d}_{k})$ without missing deadlines. To achieve this, we exploit the underlying mechanism of a wellknown schedulability analysis called DA, which uses two notions of interference defined as follows.
Definition 2. (Worstcase interference ${I}_{k}$ on ${\tau}_{k}$) The worstcase interference ${I}_{k}$ on a task ${\tau}_{k}$ in an interval $[{r}_{k},{d}_{k})$ on multiprocessors is defined as the maximum cumulative length of all the intervals in which ${J}_{k}$ is ready to execute but cannot be scheduled because of higherpriority jobs.
Definition 3. (Worstcase interference ${I}_{k\leftarrow i}$ of ${\tau}_{i}$ on ${\tau}_{k}$) The worstcase interference ${I}_{k\leftarrow i}$ of a task ${\tau}_{i}$ on a task ${\tau}_{k}$ in an interval $[{r}_{k},{d}_{k})$ on multiprocessors is defined as the maximum cumulative length of all the intervals in which ${J}_{k}$ is ready to execute but cannot be executed on any processor when the job ${J}_{i}$ of the task ${\tau}_{i}$ is executing.
Using the definition of
${I}_{k}$,
${V}_{k}$ is calculated as follows.
For a job
${J}_{k}$ to interfere at a time unit in [
${r}_{k}$,
${d}_{k}$), there are
m jobs at the time unit. By the definition of
${I}_{k\leftarrow i}$,
${I}_{k}$ is calculated as follows.
To upper bound
${I}_{k\leftarrow i}$, we use the concept of workload of a task
${\tau}_{i}$ in an interval of length
ℓ, which is defined as the maximum amount of time units required for all jobs released from
${\tau}_{i}$ in the interval of length
ℓ. As shown in
Figure 4, the leftmost job (called the carryin job) of
${\tau}_{i}$ starts its execution at
t (i.e., the beginning of the interval) and finishes it at
$t+\ell $. That is, it executes for
${C}_{i}$ without any delay. Thereafter, the following jobs are released and executed without any delay. By calculating the number of jobs executing for
${C}_{i}$ and the other jobs executing for a part of
${C}_{i}$, the workload of
${\tau}_{i}$ in an interval of length
ℓ (i.e.,
${I}_{k\leftarrow i}$) is calculated by [
18].
Figure 5 illustrates the underlying idea of DA with an example in which the target task
${\tau}_{k}$’s schedulability is judged considering its four higher priority tasks
${\tau}_{i}\in hp\left({\tau}_{k}\right)$ on
$m=3$. In the interval
$[{r}_{k}^{j},{d}_{k}^{j})$, there is only one job
${J}_{k}^{j}$ of
${\tau}_{k}$, and there is no deadline miss if
${J}_{k}^{j}$’s execution is not hindered by more than
${D}_{k}{C}_{k}+1$. As seen in
Figure 5,
${I}_{k\leftarrow i}$ can be larger than
${D}_{k}{C}_{k}+1$, and some portion of that inevitably executes in parallel with
${J}_{k}^{j}$ since we assume that each job cannot execution in parallel on more than one processor. Thus, DA limits the amount of
${I}_{k\leftarrow i}$ to
${D}_{k}{C}_{k}+1$, which refines Equation (
2) as follows.
Theorem 1. Suppose that ${\tau}_{k}\in \tau $ scheduled by a given fixedpriority scheduling algorithm is deemed schedulable by DA, and tasks in $lp\left({\tau}_{k}\right)$ do not delay ${\tau}_{k}$ more than ${V}_{k}$. Then, ${\tau}_{k}$ is still schedulable with the randomization protocol.
Proof. By the definition
${\tau}_{k}$ is schedulable if every job
${J}_{k}^{j}$ released by
${\tau}_{k}$ at
${r}_{k}^{j}$ can finish its execution within
${D}_{k}$. From Equation (
1), we have
The worstcase execution for
${J}_{k}^{j}$ is upper bounded by
${C}_{k}$, and the time in which
${J}_{k}^{j}$ is hindered by higherpriority jobs is upper bounded by
${I}_{k}$ according to Equation (
4). Therefore, if the tasks in
$lp\left({\tau}_{k}\right)$ do not delay
${\tau}_{k}$ for more than
${V}_{k}$, then every job
${J}_{k}^{j}$ of
${\tau}_{k}$ can finish its execution within
${D}_{k}$. □
4.2. Schedule Randomization Protocol
Based on the mechanism to calculate the priority inversion budget of each task ${\tau}_{i}$ explained in the previous section, we illustrate how the new schedule randomization protocol for multiprocessors operates in this section. Let ${Q}_{r}=({J}_{\left(1\right)},{J}_{\left(2\right)},\cdots ,{J}_{\left(\right{Q}_{r}\left\right)})$ be the ready queue in which active jobs are sorted in decreasing order of priority. It implies that ${J}_{\left(1\right)}$ and ${J}_{\left(\right{Q}_{r}\left\right)}$ are the highest and lowestpriority jobs in ${Q}_{r}$, respectively. We assume that TaskSuffler operates only when ${Q}_{r}$ is greater than m because all active jobs will be selected for schedule, otherwise.
The TaskSuffler for multiprocessor conducts Algorithm 1 for
${Q}_{r}>m$ at every scheduling decision. It first adds
${J}_{\left(1\right)}$ to the candidate list,
${L}_{c}$ (Line 1). If its remaining inversion budget
${v}_{\left(1\right)}$ is equal to zero, then it returns
${J}_{\left(1\right)}$ and
$(m1)$ highestpriority jobs in
${Q}_{r}$ (Lines 2–4). Otherwise, with letting
${J}_{\left(i\right)}$ be the job in the current iteration, it iterates the following for
${J}_{\left(2\right)}$ through
${J}_{\left(\right{Q}_{r}\left\right)}$ (Lines 5–11). If the remaining inversion budget
${v}_{\left(i\right)}$ of
${J}_{\left(i\right)}$ is larger than zero, it adds
${J}_{\left(i\right)}$ to the candidate list
${L}_{c}$ and considers the next job (Lines 6–7). Otherwise, it adds
${J}_{\left(i\right)}$ to the candidate list
${L}_{c}$ and stops the iteration (Lines 8–9). Then, if
${L}_{c}$ is smaller than or equal to
m, it returns all jobs in
${L}_{c}$ and
$(m{L}_{c}\left\right)$ highestpriority jobs in
${Q}_{r}$. Otherwise, it returns randomly selected
m jobs in
${L}_{c}$. After Algorithm 1 is conducted, the selected
m jobs execute until the next scheduling decision.
Algorithm 1 TaskSuffler for multiprocessors. 
 1:
${L}_{c}\leftarrow {J}_{\left(1\right)}$  2:
if${v}_{\left(1\right)}\le 0$then  3:
return ${J}_{\left(1\right)}$ and ($m1$) highestpriority jobs in ${Q}_{r}$  4:
end if  5:
for each ${J}_{\left(i\right)}\in {Q}_{r}$ for i from 2 to ${Q}_{r}$ do  6:
if ${v}_{\left(i\right)}>0$ then  7:
add ${J}_{\left(i\right)}$ to ${L}_{c}$  8:
else  9:
add ${J}_{\left(i\right)}$ to ${L}_{c}$ and goto Step 12  10:
end if  11:
end for  12:
if${L}_{c}\le m$then  13:
return all jobs in ${L}_{c}$ and ($m{L}_{c}$) highestpriority jobs in ${Q}_{r}$  14:
else  15:
return randomly selected m jobs in ${L}_{c}$  16:
end if

Let
${\tau}_{b}$ denote the task of the lowestpriority job among selected jobs, and
${\tau}^{u}$ denote the set of tasks that were not selected. The next schedule decision is made at
unless a new job arrives or any of the selected jobs finishes its execution before
${t}^{\prime}$. Thus, the remaining inversion budget of every released job belonging to a task
${\tau}_{i}\in (hp\left({\tau}_{b}\right)\cap {\tau}^{u})$ is deducted by one at each time unit until the next schedule decision will be made, a new job arrives, or any of the selected jobs finishes its execution before
${t}^{\prime}$. The remaining priority inversion budget
${v}_{i}$ of each job
${J}_{i}$ is set to
${V}_{i}$ when
${J}_{i}$ is released.
Theorem 2. Suppose that ${\tau}_{k}\in \tau $ scheduled by a given fixedpriority scheduling algorithm is deemed schedulable by DA schedulability analysis, then it is still schedulable under the schedule randomization protocol.
Proof. By Theorem 1,
${\tau}_{k}$ is schedulable if its execution is not hindered for more than
${V}_{k}$ by lowerpriority tasks.
${\tau}_{k}$’s execution is interfered by lowerpriority tasks only when
${\tau}_{k}$’s priority is lower than that of
${\tau}_{b}$, and the amount of interference from lowerpriority tasks cannot be larger than
${V}_{k}$ since the next scheduling decision is made before
${v}_{k}$ becomes zero owing to Equation (
6). □
To implement TaskShuffler to the existing scheduler, the system should be capable for tracking tasks’ remaining execution times and priority inversion budgets. Such monitoring ability is already commonly available on many realtime systems, whose aim is to guarantee that they do not exceed their execution allowances [
19,
20]. Utilizing such the ability, TaskShuffler may impose additional scheduling decisions according to the policy of TaskShuffler, compared to the vanilla scheduling algorithms (e.g., rate monotonic). It naturally increases scheduling costs such as preemption (or context switching) and migration costs. The system designers should consider how much such scheduling costs will happen for their target systems when TaskShuffler is considered to improve the schedule entropy without schedulability loss.
4.3. Schedule Entropy for Multiprocessors
Because our goal is to improve the uncertainty in scheduling to foil the fixed schedule pattern of realtime scheduling, we need to evaluate the improvement in the uncertainty of our proposed schedule randomization protocol. To overcome this issue, we use the concept of schedule entropy initially designed for a uniprocessor [
21,
22,
23]. The underlying idea of schedule entropy is to measure randomness (or unpredictability) of schedule at each time unit, called slot entropy, and derive the summation of all slot entropies over a
hyperperiod L (defined as the least common multiple of
${T}_{i}$ of all tasks
${\tau}_{i}\in \tau $). The slot entropy
${H}_{\tau}\left(t\right)$ at a time slot
t for a task set
$\tau $ is calculated as follows.
where
$Pr({\tau}_{i},t)$ is the probability mass function of a task
${\tau}_{i}$ appearing at time
t.
$Pr({\tau}_{i},t)$ is obtained empirically by observing multiple hyperperiods [
15]. Then, the schedule entropy
${H}_{\tau}$ is calculated by the summation of all slot entropies over a hyperperiod
L as follows.
According to the considered task model, we assume that all processors share the common cache and main memory. Then, it also implies that which processor is assigned to a task ${\tau}_{i}$ does not affect the level of scheduling entropy. That is, the level of scheduling entropy is influenced by whether ${\tau}_{i}$ is scheduled or not in a time slot. Such the assumption is the limitation of our study, and thus it should be considered as potential future work.
5. Evaluation
In this section, we evaluate the performance of our schedule randomization protocol with randomly generated synthetic task sets to understand the effect of our approach on various factors more fully.
We randomly generated even task sets from nine system utilization groups,
$[0.01+0.1\xb7i,0.09+0.1\xb7i]$ for
$i=0,\cdots ,8$, that is, 100 instances per group. The system utilization of a task set is defined as the sum of the utilizations of all tasks (
${\sum}_{{\tau}_{i}\in \tau}({C}_{i}/{T}_{i})$) in the task sets. We considered three different numbers of processors
$m=2,4$ and 8. Each system utilization group has five subgroups, each of which has a fixed number of tasks; for
$m=2,4$ and 8, the number of tasks for five subgroups are {
$5,7,9,11,13$}, {
$6,9,12,15,18$} and {
$7,11,15,19,23$}. Each task period
${T}_{i}$ was randomly selected from {20, 40, 80, 160, 320, 640, 1280, 2560}, and each WCET
${C}_{i}$ was selected from
$min([1,50],{T}_{i})$. A total of 100 task sets were generated for each subgroup, and thus
$7\xb73\xb75\xb7100=10,500$ task sets were generated in total. As our goal is to improve the uncertainty of the schedule without compromising schedulability, we only selected the task sets whose schedulability is guaranteed by DA schedulability. We used ratemonotonic (RM) scheduling as our base scheduling algorithm in which our proposed schedule randomization was applied. To obtain the converged schedule entropy of each task set, we conducted a simulation for 10,000 hyperperiods of the task set as it ensures less than 0.01% (recommended to obtain the converged schedule entropy [
15]) of difference in schedule entropy between those from 9999 and 10,000 hyperperiods.
Figure 6 shows the plot of average schedule entropy of each subgroup’s task sets (i.e., 100 task sets for each subgroup) over varying system utilization groups for
$m=2,4$ and 8 (Due to limited space on xaxis,
$[0.01+0.1\xb7i,0.09+0.1\xb7i]$ for
$i=0,\cdots ,8$ is represented as [0.0, 0.1], [0.1, 0.2], ⋯, [0.7, 0.8], [0.8, 0.9].). As shown in
Figure 6a, the schedule entropy of a task set is high on average when it consists of a large number of tasks (System utilization group [0.8, 0.9] exhibits an exceptional result because of heavy utilization of its task set, which result that most of the task sets exhibit zero schedule entropy). This is because a higher number of tasks with our schedule randomization protocol possibly provides larger options for tasks to be randomly selected in every time slot. For example, the schedule entropy
${H}_{\tau}\left(t\right)$ at a time slot
t of a task set
$\tau $ having two tasks
${\tau}_{i}\in \tau $ each of whose
$Pr({\tau}_{i},t)$ is 1/2 is 1, while
${H}_{\tau}\left(t\right)$ is 2 if
$\tau $ has four tasks
${\tau}_{i}\in \tau $ each of whose
$Pr({\tau}_{i},t)$ is 1/4. This implies that a larger number of tasks for each task set can improve schedule entropy. In addition,
Figure 6a demonstrates that task sets included in the groups whose system utilization is low or high (e.g., [0.0, 0.1], [0.1, 0.2], [0.7, 0.8] or [0.8, 0.9]) result in relatively low average schedule entropy while the others (e.g., [0.2, 0.3]–[0.6, 0.7]) results in high average schedule entropy. Because the task sets with low system utilization have less WCET, no process operates (i.e., processors are idling) in most of the time slots. When it comes to high utilization, most of the tasks have low
${V}_{i}$ values; therefore, the chances of tasks to be randomly selected are quite low. Therefore, a low schedule entropy results in both cases.
From
Figure 6a–c, we can observe that the average schedule entropy of task sets decreases as the number of processors
m increases. This is mainly due to the underlying pessimism of the DA schedulability analysis in calculating
${I}_{k}$ in Equation (
4). As
Figure 5 implies, the DA schedulability analysis assumes that the execution corresponding to
${I}_{k\leftarrow i}$ is performed as much as possible in the interval [
${r}_{k}^{j}$,
${r}_{k}^{j}+{D}_{k}{C}_{k}+1$) to upper bound
${I}_{k}$. However, this does not happen in most cases since two jobs released consecutively from the same task may execute at intervals from each other, which implies that the amount of execution contributing to
${I}_{k}$ is overestimated under the DA schedulability analysis. Such pessimism of the DA schedulability analysis increases for a larger value of
m. As our schedule randomization protocol is based on the DA schedulability analysis to derive
${V}_{i}$, task sets with a lower value of
${V}_{i}$ (from a larger value of
m) results in a lower average schedule entropy.
While
Figure 6 presents the average schedule entropy over varying system utilization groups,
Table 1,
Table 2 and
Table 3 show the maximum schedule entropy obtained from each setting. As the minimum schedule entropy of every setting is zero,
Table 1,
Table 2 and
Table 3 also represent the range of schedule entropy that can be obtained from each setting. “” in the tables represents a value lower than 0.1, and we exclude rows of the tables if all values corresponding to the row are “”. The trends shown in
Figure 6a–c also appear in
Table 1,
Table 2 and
Table 3, but the maximum schedule entropy of task sets in the high system utilization group are relatively high compared to the average schedule entropy of those task sets. This indicates that a very low number of task sets in the high system utilization group shows exceptionally high schedule entropy from a certain task parameter setting following the considered task set generation method, and the other task sets are with zero schedule entropies.
One may wonder whether much additional scheduling overhead is required to apply our schedule randomization protocol into the existing scheduling algorithm. Note that the schedule decision on preemptive scheduling algorithm (basically considered in our paper) without the schedule randomization protocol is made only when a job finishes its execution or a new job is released. In addition, an additional schedule decision stemming from the schedule randomization protocol is made when
${v}_{i}$ (i.e., the remaining priority inversion budget value of
${V}_{i}$) of a job becomes zero.
Figure 7 shows the ratio between the number of schedule decisions made by naive RM and that made by RM with the schedule randomization protocol. As shown in
Figure 7, for task sets with high system utilization or for larger
m shows less schedule decision ratio. With high system utilization or larger
m, each task has a lower priority inversion budget as aforementioned, and the schedule randomization protocol works rarely with such settings. Overall, a high schedule decision ratio implies a larger scheduling overhead, and thus the system designers should carefully consider the tradeoff between scheduling overhead and the degree of security they want to achieve for their target system.
6. Related Work
The problem of information leakage for realtime systems has been addressed in several studies. Mohan et al. considered realtime tasks with different security levels and focused on information leakage on shared computing resources (e.g., RAM and cache). They proposed a mechanism for FP scheduling to flush the status of shared resources conditionally, which reduces the chances of an attacker from obtaining sensitive information of the resources [
24]. Because they incorporated a security mechanism into the existing FP scheduling, an additional timing overhead was inevitably required. Therefore, they proposed a new sufficient schedulability analysis to accommodate that fact. In [
25], an exact schedulability was proposed to improve the analytical capability. In addition, this work was extended to mixedcriticality systems in [
26]
The aforementioned studies addressed the issues only for nonpreemptive scheduling; therefore, Pellizzoni et al. extended this work to preemptive scheduling [
27]. They extended it to a more general task model, and proposed an optimal priority assignment method that determines the task preemptibility.
Another approach to improve the security of realtime systems is to randomize the schedules without compromising schedulability. TaskShuffler addressed in this study was proposed by Yoon et al. for a preemptive FP scheduling algorithm [
15]. The goal of TaskShuffler is to improve uncertainty in schedule and reduce the success ratio of timing inference attacks simultaneously. Kr¨uger et al. proposed an online schedule randomization protocol for timetriggered systems [
28]. While the aforementioned two approaches are applicable to uniprocessor platforms, we focus on multiprocessor platforms.