Period Adaptation for Continuous Security Monitoring in Multicore Real-Time Systems
Monowar Hasan, Sibin Mohan, Rodolfo Pellizzoni, Rakesh B. Bobba
PPeriod Adaptation for Continuous Security Monitoring inMulticore Real-Time Systems
Monowar Hasan * , Sibin Mohan * , Rodolfo Pellizzoni † , Rakesh B. Bobba ‡ * {mhasan11, sibin}@illinois.edu, † [email protected], ‡ [email protected] ABSTRACT
We propose a design-time framework (named HYDRA-C) forintegrating security tasks into partitioned real-time systems (RTS)running on multicore platforms. Our goal is to opportunistically execute security monitoring mechanisms in a ‘continuous’ manner– i.e., as often as possible, across cores, to ensure that securitytasks run with as few interruptions as possible. Our frameworkwill allow designers to integrate security mechanisms withoutperturbing existing real-time (RT) task properties or executionorder. We demonstrate the framework using a proof-of-conceptimplementation with intrusion detection mechanisms as securitytasks. We develop and use both, (a) a custom intrusion detectionsystem (IDS), as well as (b) Tripwire – an open source dataintegrity checking tool. These are implemented on a realistic roverplatform designed using an ARM multicore chip. We comparethe performance of HYDRA-C with a state-of-the-art RT securityintegration approach for multicore-based RTS and find that ourmethod can, on average, detect intrusions 19.05% faster withoutimpacting the performance of RT tasks.
Limited resources in terms of processing power, memory, energy, etc. coupled with the fact that security was not considered a designpriority has led to the deployment of a large number of real-time systems (RTS) that include little to no security mechanisms.Hence, retrofitting such legacy RTS with general-purpose securitysolutions is a challenging problem since any perturbation of thereal-time (RT) constraints (runtimes, periods, task execution orders,deadlines, etc. ) could be detrimental to the correct and safe operationof RTS. Besides, security mechanisms need to be designed in sucha way that an adversary can not easily evade them. Successfulattacks/intrusions into RTS are often aimed at impacting the safetyguarantees of such systems, as evidenced by recent intrusions( e.g., attacks on control systems [2, 3], automobiles [4, 5], medicaldevices [6], etc. to name but a few). Systems with RT propertiespose unique security challenges – these systems are requiredto meet stringent timing requirements along with strong safetyrequirements. Limited resources ( i.e., computational power, storage,energy, etc. ) prevent security mechanisms that have been primarilydeveloped for general purpose systems from being effective forsafety-critical RTS.In this paper we aim to improve the security posture of RTSthrough integration of security tasks while ensuring that theexisting RT tasks are not affected by such integration. The security In partitioned scheduling (a widely accepted multicore scheduling scheme), tasks arestatically partitioned onto identical cores ( i.e., runtime migration across cores is notpermitted) [1]. Table 1: Example of Security TasksSecurity Task Approach/Tools
File-system checking Tripwire [17], AIDE [18], etc.
Network packet monitoring Bro [19], Snort [20], etc.
Hardware event monitoring Statistical analysis basedchecks [21] using performancemonitors ( e.g., perf [22],
OProfile [23], etc. )Application specificchecking Behavior-based detection (seethe related work [11–13, 24])tasks considered could be carrying out any one of protection,detection or response-based operations, depending on the systemrequirements. For instance, a sensor measurement correlation taskmay be added for detecting sensor manipulation or a changedetection task (or other intrusion detection programs) may beadded to detect changes/intrusions into the system. In Table 1 wepresent some examples of security tasks that can be integrated intolegacy systems (this is by no stretch meant to be an exhaustive list).Note that the addition of any security mechanisms (such as IDS,encryption/authentication, behavior-based monitoring, etc. ) mayrequire modification of the system or the RT task parameters aswas the case in prior work [7–15].Further, to provide the best protection, security tasks mayneed to be executed as often as possible . If the interval betweenconsecutive checking events is too large then an attacker mayremain undetected and cause harm to the system between twoinvocations of the security task. In contrast, if the security tasks areexecuted very frequently, it may impact the schedulability of the RT(and other security) tasks. The challenge is then to determining theright periods ( i.e., minimum inter-invocation time) for the securitytasks [16].As a step towards enabling the design of secure RT platforms,opportunistic execution [25, 26] has been proposed as a potentialway to integrate security mechanisms into legacy RTS – this allowsthe execution of security mechanisms as background serviceswithout impacting the timing constraints of the RT tasks. Otherapproaches have been built on this technique for integrating tasksinto both legacy and non-legacy systems [7–11, 27, 28]. However,most of that work was focused on single core RTS (that area majority of such systems in use today). However, multicore processors have found increased use in the design of RTS to improveoverall performance and energy efficiency [29, 30]. While the useof such processors increases the security problems in RTS ( e.g., due to parallel execution of critical tasks) [31] to our knowledgevery few security solutions have been proposed in literature [26].In prior work (called HYDRA) [26] researchers have developed a a r X i v : . [ c s . O S ] M a r echanism for integrating security into multicore RTS. Howeverthis work uses a partitioned scheduling approach and does not allowruntime migration of security tasks across cores. We show that thisresults in delayed detection of intrusions as the security tasks arenot able to execute as frequently. Our main goal in this paper is to raise the responsiveness of such security tasks by increasing theirfrequency of execution . For instance, consider an intrusion detectionsystem (IDS) – say one that checks the integrity of file systems. Ifsuch a system is interrupted (before it can complete checking theentire system), then an adversary could use that opportunity tointrude into the system and, perhaps, stay resident in the part of thefilesystem that has already been checked (assuming that the IDSis carrying out the check in parts). If, on the other hand, the IDStask is able to execute with as few interruptions as possible ( e.g. ,by moving immediately to an empty core when it is interrupted),then there is much higher chance of success and, correspondingly,a much lower chance of a successful adversarial action. Our Contributions.
In this paper, we propose a design-timemethodology and a framework named HYDRA-C for partitioned RTS that (a) leverages semi-partitioned scheduling [35] to enable continuous execution of security tasks ( i.e., execute as frequently aspossible) across cores, and (b) does not impact the timing constraintsof other, existing, RT tasks.HYDRA-C takes advantage of the properties of a multicoreplatform and allows security tasks to migrate across availablecores and execute opportunistically ( i.e., when the RT tasks are notrunning). This framework extends existing work [26] and ensuresbetter security ( e.g., faster detection time) and schedulability (seeSection 5). HYDRA-C is able to do this without violating timingconstraints for either the existing RT tasks or the security ones(Section 3). We develop a mathematical model and iterative solutionthat allows security tasks to execute as frequently as possiblewhile still considering the schedulability constraints of other tasks(Section 4). In addition, we also present an implementation ona realistic ARM-based multicore rover platform (running a RTvariant of Linux system and realistic security applications). We thenperform comparisons with the state-of-the-art [26] (Section 5.1).Finally, we carry out a design space exploration using syntheticworkloads and study trade-offs for schedulability and security.Our evaluation shows that proposed semi-partitioned approachcan achieve better execution frequency for security tasks andconsequently quicker intrusion detection (19 .
05% faster on average)when compared with both fully-partitioned and global schedulingapproaches while providing the same or better schedulability(Section 5.2).
Note:
We do not target our framework towards any specificsecurity mechanism – our focus is to integrate any designer-provided security solution into a multicore-based RTS. In ourexperiments we used Tripwire [17] (a data integrity checkingtool) as well as our in-house custom-developed malicious kernelmodule checker to demonstrate the feasibility of our approach – We discuss this issue further in Section 5. Since this is the commonly used multicore scheduling approach for many commercialand open-source OSs (such as OKL4 [32], QNX [33], RT-Linux [34], etc. ) – mainly dueto its simplicity and efficiency [1, 26]. the integration framework proposed in this paper is more broadlyapplicable to other security mechanisms.
Consider a set of N R RT tasks Γ R = { τ , τ , · · · , τ N R } , scheduled ona multicore platform with M identical cores M = { π , π , · · · , τ M } .Each RT task τ r releases an infinite sequence of task instances,also called jobs , and is represented by the tuple ( C r , T r , D r ) where C r is the worst-case execution time (WCET), T r is the minimuminter-arrival time ( e.g., period) and D r is the relative deadline.The utilization of each task is denoted by U r = C r T r . We assumeconstrained deadlines for RT tasks ( e.g., D r ≤ T r ) and that the taskpriorities are assigned according to rate-monotonic (RM) [36] order( e.g., shorter period implies higher priority).All events in the system happen with the precision of integerclock ticks ( i.e., processor clock cycles), that is, any time t involvedin scheduling is a non-negative integer. In this paper we consider RTtasks that are scheduled using partitioned fixed-priority preemptivescheme [30] and assigned to the cores using a standard taskpartitioning algorithm [1, 30]. We further assume that the RT tasksare schedulable , viz., the worst-case response time (WCRT), denotedas R r , is less than deadline ( e.g., R r ≤ D r , ∀ τ r ) and the followingnecessary and sufficient schedulability condition holds for each RTtasks τ r assigned to any given core π m [1]: ∃ t : 0 < t ≤ D r and C r + (cid:213) τ i ∈ hp ( τ r , π m ) (cid:24) tT i (cid:25) C i ≤ t , (1)where hp ( τ r , π m ) denotes the set of RT tasks with higher prioritythan τ r assigned to core π m . Our focus is on integrating given security mechanisms abstractedas security tasks into a legacy multicore RTS without impactingthe RT functionality of the RTS. While we use specific intrusiondetection mechanisms ( e.g.,
Tripwire) to demonstrate our approach,our approach is somewhat agnostic to the security mechanisms. Thesecurity model used and the design of security tasks are orthogonalproblems. Since we aim to maximize the frequency of execution ofsecurity tasks, security mechanisms whose performance improveswith frequency of execution ( e.g., intrusion monitoring anddetection tasks) benefit from our framework.
We propose to improve the security posture of multicore based RTsystems by integrating additional periodic security tasks ( e.g., tasksthat are specifically designed for intrusion detection purposes).We highlight that HYDRA-C abstracts security tasks and allowsdesigners to execute any given techniques . Our focus here is onintegration of a given set of security tasks ( e.g., intrusion detectionmechanisms) in an existing multicore RTS without impactingthe RT task parameters ( e.g., WCET, periods, etc. ) or their taskexecution order. In general, the addition of security mechanismsmay increase the execution time of existing tasks [7, 8] or reduceschedulability [15]. As we mentioned earlier, our focus is on legacy ..…..…..….. Period Security Task TimeTask activation Schedule (vanilla)Schedule (with security task)Core 0Core 1
RT Task 1 (core 0)RT Task 2 (core 1)
Core idle (slack time)Core 0Core 1
Figure 1: Illustration of our security integration frameworkfor a dual-core platform: two RT tasks (blue and green)are statically assigned to two cores (core 0 and core 1,respectively). We propose to integrate a security task (red)that will execute with lowest priority and can be migratedto ether core (whichever is idle) at runtime. multicore systems where designers may not have enough flexibilityto modify system parameters to integrate security mechanisms. Weaddress this problem by allowing security tasks to execute witha priority lower than all the RT tasks, i.e., leverage opportunisticexecution [25, 26]. This way, security tasks will only execute duringthe slack time ( e.g., when a core is idle) and the timing requirementsof the RT tasks will not be perturbed. However, in contrast to priorwork (HYDRA) [26] where the security tasks are statically boundto their respective cores, in this paper we allow security tasks tocontinuously migrate at runtime ( i.e., the combined taskset withRT and security tasks follows a semi-partitioned scheduling policy)whenever any core is available ( e.g., when other RT or higher-priority security tasks are not running). An illustration of HYDRA-C is presented in Fig. 1 where two RT tasks (represented by blueand green rectangles) are partitioned into two cores and a newlyadded security task (red rectangle) can move across cores.As we shall see in Section 5, allowing security tasks to executeon any available core will give us the opportunity to executesecurity tasks more frequently ( e.g., with shorter period) and thatleads to better responsiveness (faster intrusion detection time).One fundamental question with our security integration approachis to figure out how often to execute security tasks so that thesystem remains schedulable ( e.g.,
WCRT is less than period), andalso can execute within a designer provided frequency bound(so that the security checking remains effective). This is differentwhen compared to scheduling traditional RT tasks since the RTtask parameters ( e.g., periods) are often derived from physicalsystem properties and cannot be adjusted due to control/applicationrequirements. We now formally define security tasks.
Security Tasks.
Let us include a set of N S security tasks Γ S = { τ , τ , · · · , τ N S } in the system. We adopt the periodic securitytask model [25] and represent each security task by the tuple ( C s , T s , T maxs ) where C s is the WCET, T s is the (unknown) period( e.g., T s is the monitoring frequency) and T maxs is a designerprovided upper bound of the period – if the period of the securitytask is higher than T maxs then the responsiveness is too low andsecurity checking may not be effective.We assume that priority of the security tasks are distinct andspecified by the designers ( e.g., derived from specific security requirements). Security tasks have implicit deadlines, i.e., they needto finish execution before the next invocation. We also assume thattask migration and context switch overhead is negligible comparedto WCET of the task. Our goal here is to find a minimum period T s ≤ T maxs (so that the security tasks can execute more frequently)such that the taskset remains schedulable ( e.g., ∀ τ s ∈ Γ S : R s ≤ T s where R s is the WCRT of τ s ). The actual periods for the security tasks are not known – we needto find the periods that ensures schedulability and gives us bettermonitoring frequency. Mathematically this can be expressed asthe following optimization problem: minimize T s , ∀ τ s ∈ Γ S (cid:205) τ s ∈ Γ S T s , subject to R s ≤ T s ≤ T maxs , ∀ τ s ∈ Γ S . This is a non-trivial problem since theperiod of τ s can be anything in [R s , T maxs ] and the response time R s is variable as it depends on the period of other higher prioritysecurity tasks. We first derive the WCRT of the security tasks anduse it as a (lower) bound to find the periods. Our WCRT calculationfor security tasks is based on the existing iterative analysis forglobal multicore scheduling [37–39] and we modify it to accountthe fact that RT tasks are partitioned. We start by briefly reviewing the relevant terminology andparameters. We are interested in determining the response timeof a job τ ks of task τ s ( e.g., job under analysis) using an iterativemethod and the response time in each iteration is denoted by x . Definition 1 (Busy Period).
The busy period of τ ks is the maximalcontinuous time interval [ t , t ) (until τ ks finishes) where all thecores are executing either higher priority tasks or τ ks itself. Definition 2 (Interference).
Given task τ i , the interference I τ s ← τ i caused by τ i on τ ks is the number of time units in the busy periodwhen τ i executes while τ ks does not.Note that the job under analysis τ ks cannot execute if all coresare busy with higher priority tasks; hence, the length of the busyperiod is at most (cid:106) Ω s M (cid:107) + C s by definition, where Ω s is the sumof the interference caused by all higher priority tasks on τ ks . Tocompute the value of I τ s ← τ i , we rely on the concept of workload . Definition 3 (Workload).
The workload W i ( x ) of a task τ i in awindow of length x represents the accumulated execution time of τ i within this time interval.It remains to compute the workload and correspondinginterference for each higher priority task τ i . We first show how todo so for RT tasks and then for security tasks with higher prioritythan τ s . Since RT tasks are statically partitioned to cores and they havehigher priority than any task that is allowed to migrate betweencores, the worst-case workload for RT tasks can be trivially obtained The calculation of WCRT is presented in Section 4.4. ime % % + ($ $ $ ( Time % % + ($ $ $ (ℛ Figure 2: Workload of the RT tasks for a window of size x .The arrival time of the task τ i is denoted by a i . based on the same critical instant used for single core fixed-priorityscheduling case [36].Lemma 1. For a given core π m , the maximum workload of RT tasksexecuted on π m in any possible time interval of length x is obtainedwhen all RT tasks are released synchronously at the beginning of theinterval. Proof. Since RT tasks are partitioned and they have higherpriorities than security tasks, the schedule of RT tasks executed on π m does not depend on any other task in the system. Now considerany interval [ t , t + x ) of length x . We show that we can obtain aninterval [ t ′ , t ′ + x ) where all tasks are released at t ′ , such that theworkload of RT tasks on π m is higher in [ t ′ , t ′ + x ) compared to [ t , t + x ) . First step : let t ′ be the earliest time such that π m continuouslyexecutes RT tasks in [ t ′ , t ) ; if such time does not exist, then let t ′ = t . By definition, π m does not execute RT tasks at time t ′ − [ t ′ , t ) , the workloadof RT tasks in [ t ′ , t ′ + x ) cannot be smaller than the workload in [ t , t + x ) . Second step : since π m is idle at t ′ −
1, no job of RT tasks on π m released before t ′ can contribute to the workload in [ t ′ , t ) .Hence, the workload can be maximized by anticipating the releaseof each RT task τ r so that it corresponds with t ′ . This concludesthe proof. □ Let Γ π m R ⊆ Γ R denote the set of RT tasks partitioned to core π m .Based on Lemma 1, an upper bound to the workload of RT tasks on π m can be obtained by assuming that each RT task τ r is released atthe beginning of the interval and each job of τ r executes as earlyas possible after being released, as shown in Fig. 2. We thus obtainthe workload for RT task τ r : W Rr ( x ) = (cid:22) xT r (cid:23) C r + min ( x mod T r , C r ) , (2)and summing over all RT tasks on π m yields a total workload (cid:205) τ i ∈ Γ πmR W Ri ( x ) . Finally, we notice that by definition the interferencecaused by a group of tasks executing on the same core π m on τ s cannot be greater than x − C s +
1. Therefore, the maximuminterference caused by RT tasks on π m to τ s can be bounded as: I τ s ← Γ πmR (cid:16) x , (cid:213) τ i ∈ Γ πmR W Ri ( x ) (cid:17) = min (cid:169)(cid:173)(cid:173)(cid:171) (cid:213) τ i ∈ Γ πmR W Ri ( x ) , x − C s + (cid:170)(cid:174)(cid:174)(cid:172) . (3)The ‘ +
1’ term in the upper bound of the interference ( e.g.,
Eq. (3))ensures the convergence of iterative search for the response time(recall from Section 4.1 that at each iteration the response timeis denoted by x ) to the correct value [40]. For example, when theiterative search for the response time is started with x = C s ( i.e., Time ! " − $ " % Arrival ( $ " ) Finish ( ! " ) $ " − % Busy Period
Figure 3: Extension of busy period for bounding the numberof carry-in higher priority security tasks.
Time % % + ($ $ $ ( Time % % + ( $ $ $ (ℛ Figure 4: Illustration of carry-in task for a window of size x . x − C s = (cid:32) (cid:205) τ i ∈ Γ πmR W Ri ( x ) , x − C s (cid:33) = We next consider the workload of security tasks with higher prioritythan τ s . The workload computation depends on the arrival time ofthe task relative to the beginning of the busy period, as specified inthe following definition. Definition 4 (Carry-in).
A task τ i is called a carry-in task if thereexists one job of τ i that has been released before the beginning of agiven time window of length x and executes within the window. Ifno such job exists, τ i is referred to as a non-carry-in task.Generally (but not always), the workload of a task τ i in thebusy period is higher if τ i is a carry-in task than a non-carry-intask. Hence, it is important to limit the number of higher prioritycarry-in tasks. To this end, we follow an approach similar to priorresearch [37, 39] and extend the busy period of τ ks from its arrivaltime (denoted by a s ) to an earlier time instance t (see Fig. 3)such that during any time instance t ∈ [ t , a s ) all cores are busyexecuting tasks with higher priority than τ s . Note that by definition,this implies that there was at least one free core ( i.e., not executinghigher priority tasks) at time t − At most M − higher priority tasks can have carry-inat time t . Proof. The maximum number of higher priority tasks that canhave carry-in at t is M − M higher priority tasks active at time t − □ Since Lemma 2 holds for all tasks with higher priority than τ s ,an immediate corollary is that the number of security tasks withcarry-in at t also cannot be larger than M −
1. If a security task τ i does not have carry-in, its workload is maximized when the taskis released at the beginning of the busy interval. Hence, we cancalculate the workload bound W S NC i ( x ) for the interval x usingEq. (2), e.g., W S NC i ( x ) = (cid:106) xT i (cid:107) C i + min ( x mod T i , C i ) . Likewise, theworkload bound for a carry-in security task τ i in an interval oflength x starting at t is given by (see Fig. 4): W S CI i ( x ) = W S NC i ( max ( x − ¯ x i , )) + min ( x , C i − ) , (4) here ¯ x i = C i − + T i − R i . We can bound the workload of the firstcarry-in job to C i − t − τ i can bebounded as follows: I τ s ← τ i ( x , W i ( x )) = min ( W i ( x ) , x − C s + ) , (5)where W i ( x ) is either W S NC i ( x ) or W S CI i ( x ) . Notice that the WCRTand periods of security task in the carry-in workload function (seeEq. (4)) is actually an unknown parameter. However, we follow aniterative scheme that allows us to calculate the period and WCRT ofall higher priority security tasks before we calculate the interferencefor task τ s (refer to Section 4.5 for details). Let hp S ( τ s ) denote the set of security tasks with a higher prioritythan τ s . Note that we do not know which (at most) M − hp S ( τ s ) have carry-in. In order to derive the WCRT of τ s ,let us define Z τ s ⊂ Γ × Γ as the set of all partitions of hp S ( τ s ) intotwo subsets Γ NCs and Γ CIs ( e.g., the non overlapping set of carry-inand non-carry-in tasks) such that: Γ NCs ∩ Γ CIs = ∅ , Γ NCs ∪ Γ CIs = hp S ( τ s ) , and | Γ CIs | ≤ M − , e.g., there are at most M − e.g., Γ NCs and Γ CIs ),we can calculate the total interference experienced by τ s as follows: Ω s ( x , Γ NCs , Γ CIs ) = (cid:213) π m ∈M I τ s ← Γ πmR (cid:16) x , (cid:213) τ i ∈ Γ πmR W Ri ( x ) (cid:17) + (cid:213) τ i ∈ Γ NCs I τ s ← τ i (cid:16) x , W S NC i ( x ) (cid:17) + (cid:213) τ i ∈ Γ CIs I τ s ← τ i (cid:16) x , W S CI i ( x ) (cid:17) . (6)For a given Γ NCs , Γ CIs sets response time R s |( Γ NCs , Γ CIs ) will bethe minimal solution of the following iteration [37]: x = (cid:36) Ω s ( x , Γ NCs , Γ CIs ) M (cid:37) + C s . (7)We can solve this using an iterative fixed-point search with theinitial condition x ( ) = C s . The search terminates if there exists asolution ( i.e., x = x ( k ) = x ( k − ) for some iteration k ) or when x ( k ) > T maxs for any iteration k since τ s becomes trivially unschedulablefor WCRT greater than T maxs . Finally we can calculate the WCRTof τ s as follows: R s = max ( Γ NCs , Γ CIs ) ∈Z τs R s |( Γ NCs , Γ CIs ) . (8) The security task τ s remains schedulable with any period T s ∈[R s , T maxs ] . However as mentioned earlier, the calculation of R s requires us to know the period and response time of other highpriority tasks τ h ∈ hp S ( τ s ) . Also if we arbitrarily set T s = R s (sincethis allows us to execute security tasks more frequently) it maynegatively affect the schedulability of other tasks that are at a lowerpriority than τ s because of a high degree of interference from τ s . Note that the worst-case is when the job arrives at t ( i.e., a s = t ). Algorithm 1
Period Selection
Input:
Set of real-time and security tasks Γ = Γ R ∪ Γ S Output:
Periods of the security tasks, T (if the security tasks are schedulable); Unschedulable otherwise1: Set T s : = T maxs and calculate R s for ∀ τ s ∈ Γ S if ∃ τ s such that R s > T maxs then return Unschedulable end if for each security task τ s ∈ Γ S (from higher to lower priority) do /* Find period for which all lower priority tasks are schedulable */
7: Find minimum T ∗ s ∈ [R s , T maxs ] using Algorithm 2 such that ∀ τ j ∈ lp ( τ s ) remains schedulable ( e.g., R j ≤ T maxj )8: Update R j for ∀ τ j ∈ lp ( τ s ) considering the interference with new period T ∗ s end for return T : = [ T ∗ s ] ∀ τs ∈ Γ S /* return the periods */ Hence, we developed an iterative algorithm that gives us a trade-offbetween schedulability and monitoring frequency.Our proposed solution (refer to Algorithm 1 for a formaldescription) works as follows. We first fix the period of each securitytask T maxs and calculate the response time R s using the approachpresented in Section 4.3 (Line 1). If there exists a task τ j such that R j > T maxj we report the taskset as unschedulable (Line 2) sinceit is not possible to find a period for the security tasks within thedesigner provided bounds – this unschedulability result will helpthe designer in modifying the requirements (and perhaps RT tasks’parameters, if possible) accordingly to integrate security tasks forthe target system. If the taskset is schedulable with T maxs , we theniteratively optimize the periods from higher to lower priority order(Lines 5-9) and return the period (Line 10). To be specific, for eachtask τ s ∈ Γ S we perform a logarithmic search [41, Ch. 6] (seeAlgorithm 2 for the pseudocode) and find the minimum period T ∗ s within the range [ R s , T maxs ] such that all low priority tasks (denotedas lp ( τ s ) ) remain schedulable, e.g., ∀ τ j ∈ lp ( τ s ) : R j ≤ T maxj (Line7). Note that since we perform these steps from higher to lowerpriority order, WCRT and period of all higher priority tasks ( e.g., ∀ τ h ∈ hp ( τ s ) ) are already known. We then update the responsetimes of all low priority task τ j ∈ lp ( τ s ) considering the interferencefrom the newly calculated period T ∗ s (Line 8) and repeat the searchfor next security task. We evaluate HYDRA-C on two fronts: (i) a proof-of-conceptimplementation on an ARM-based rover platform with securityapplications – to demonstrate the viability of our scheme in arealistic setup (Section 5.1); and (ii) with synthetically generatedworkloads for broader design-space exploration (Section 5.2). Ourimplementation code will be made available in a public, open-sourced repository [42].
We implemented our ideas on arover platform manufactured by Waveshare [43]. The roverhardware/peripherals ( e.g., wheel, motor, servo, sensor, etc. ) arecontrolled by a Raspberry Pi 3 (RPi3) Model B [44] SBC (singleboard computer). The RPi3 is equipped with a 1.2 GHz 64-bitquad-core ARM Cortex-A53 CPU on top of Broadcom BCM2837 lgorithm 2 Calculation of Minimum Feasible Period for theSecurity Task τ s Input:
Set of real-time and security tasks Γ = Γ R ∪ Γ S Output:
A feasible period T ∗ s for the security task under analysis ( i.e., τ s )1: Define T ls : = R s , T rs : = T maxs , T cs : =
2: Set (cid:98) T s : = { T maxs } /* Initialize a variable to store the set of feasible periods */ while T ls < = T rs do
4: Update T cs : = ⌊ Tls + Trs ⌋ if ∃ τ j ∈ lp ( τ s ) such that τ j is not schedulable with T s = T cs then /* Increase the period of τ s to make the taskset schedulable (e.g., by reducingthe interference) */
7: Update T ls : = T cs + else /* Taskset is schedulable with T cs */ (cid:98) T s : = (cid:98) T s ∪ { T cs } /* Add T cs to the feasible period list */ /* Check schedulability with smaller period for next iteration */
12: Update T rs : = T cs − end if end while
15: Set T ∗ s : = min (cid:16) (cid:98) T s (cid:17) /* Find the minimum period from the set of feasible periods */ return T ∗ s /* return the period of τ s */ SoC (system-on-chip). In our experiments we focus on a dual-core setup ( e.g., activated only core0 and core1 ) and disabled theother two cores) – this was done by modifying the boot commandfile /boot/cmdline.txt and set the flag maxcpus =2. The basehardware unit of the rover is connected with RPi3 using a 40-pinGPIO (general-purpose input/output) header. The rover supportsomni-directional movement and can move avoiding obstacles usingan infrared sensor ( e.g.,
ST188 [45]). We also attached a camera (RPi3camera module) that can capture static images (3280 × e.g., base chassis, adapter, etc. ) are available on the vendor website [43]. We implementedour security integration scheme in Linux kernel 4.9 and enabledreal-time capabilities by applying the PREEMPT_RT patch [34](version 4.9.80-rt62-v7+). In our experiments the rover movedaround autonomously and periodically captured images (and storedthem in the internal storage). We assumed implicit deadlines forRT tasks and considered two RT tasks: (a) a navigation task – thatavoids obstacles (by reading measurements from infrared sensor)and navigates the rover and (b) a camera task that captures andstores still images. We do not make any modifications to the vendorprovided control codes ( e.g., navigation task). In our experimentswe used the following parameters ( C r , T r ) : ( , ) ms and ( , ) ms, for navigation and camera tasks, respectively ( i.e., total RT task utilization was 0 . ) . We calculated the WCETvalues using ARM cycle counter registers (CCNT) and set periodsin a way that the rover can navigate and capture images withoutoverloading the RPi3 CPU. Since CCNT is not accessible by default,we developed a Linux loadable kernel module and activated theregisters so that our measurement scripts can access counter values.To integrate security into this rover platform, we included twoadditional security tasks: (a) an open-source security application,Tripwire [17], that checks intrusions in the image data-store and (b) our custom security task that checks current kernel modules(as a preventive measure to detect rootkits) and compares with anexpected profile of modules. The WCET of the security tasks were5342 ms and 223 ms, respectively and the maximum periods of Table 2: Summary of the Evaluation PlatformArtifact Configuration/Tools
Platform 1.2 GHz 64-bit Broadcom BCM2837CPU ARM Cortex-A53Memory 1 GigabyteOperating System Debian Linux (Raspbian Stretch Lite)Kernel version Linux Kernel 4.9Real-time patch PREEMPT_RT 4.9.80-rt62-v7+Kernel flags
CONFIG _ PREEMPT _ RT _ FULL enabledBoot parameters maxcpus =2, force _ turbo =1, arm _ freq =700, arm _ freq _ min =700WCET measurement ARM cycle counter registersTask partition Linux taskset HYDRA-C HYDRA D e t e c t i on T i m e ( cyc l e c oun t ) (a) HYDRA-C HYDRA N u m be r o f C on t e x t S w i t c he s (b) Figure 5: Experiments with rover platform: (a) time (cyclecounts) to detect intrusions; (b) average number of contextswitches. On average our scheme can detect the intrusionsfaster without impacting the performance of RT tasks. security tasks were assumed to be 10000 ms ( e.g., total systemutilization is at least 0 . + . = . taskset utility [46] for partitioning tasks to the cores and thetasks were scheduled using Linux native sched_setscheduler() function. For accuracy of our measurements we disabled all CPUfrequency scaling features in the kernel and executed RPi with aconstant frequency ( e.g.,
700 MHz – the default value). The systemconfigurations and tools used in our experiments are summarizedin Table 2.We compared the performance of our scheme with prior work,HYDRA [26]. In that work, researchers proposed to staticallypartition the security tasks among the multiple cores – toour knowledge HYDRA is the state-of-the-art mechanism forintegrating security in legacy multicore-based RT platforms. Thekey idea in HYDRA was to allocate security tasks using a greedybest-fit strategy: for each task, allocate it to a core that givesmaximum monitoring frequency ( i.e., shorter period) withoutviolating schedulability constraints of already allocated tasks.
We observed the performanceof HYDRA-C by analyzing how quickly an intrusion can be detected .We considered the following two realistic attacks : (i) an ARM Note: our focus here is on the integration of any given security mechanisms ratherthe detection of any particular class of intrusions. Hence we assumed that there wereno zero-day attacks and the security tasks were able the detect the correspondingattacks correctly ( i.e., there were no false-positive/negative errors) – although the able 3: Simulation ParametersParameter Values Process cores, M { , } Number of real-time tasks, N R [ × M , × M ] Number of security tasks, N S [ × M , × M ] Period distribution (RT and security tasks) Log-uniformRT task allocation Best-fitRT task period, T r [ , ] msMaximum period for security tasks, T maxs [ , ] msMinimum utilization of security tasks At least 30% ofRT tasksBase utilization groups 10Number of taskset in each configuration 250shellcode [47] that allows the attacker to modify the contents ofthe image data-store – this attack can be detected by Tripwire; (ii) arootkit [48] that intercepts all the read() system calls – our customsecurity task can detect the presence of the malicious kernel modulethat is used to inject the rootkit. For each of our experimental trialswe launched attacks at random points during program execution( i.e., from the RT tasks) and used ARM cycle counters to measurethe detection time. In Fig. 5a we show the average time to detectboth the intrusions (in terms of cycle counts, collected from 35trials) for HYDRA-C and HYDRA schemes. From our experimentswe found that, on average, our scheme can detect intrusions 19 . e.g., shorter period) in general and that leads tofaster detection times.We next measured the overhead of our security integrationapproach in terms of number of context switches (CS). For each ofthe trials we observed the schedule of the RT and security tasks for45 seconds and counted the number of CS using the Linux perf tool [22]. In Fig. 5b we show the number of CS (y-axis in the figure)for HYDRA-C and HYDRA schemes (for 35 trials). As shown inthe figure, our approach increases the number of CS (since wepermit migration across cores) compared to the other scheme thatstatically partitions security tasks. From our experiments we foundthat, on average, our scheme increases CS by 1 .
75 times. However,this increased CS overhead does not impact the deadlines of RT tasks (since the security tasks always execute with a priority lower thanthe RT tasks) and thus may be acceptable for many RT applications.
We also conducted experiments with (randomly generated)synthetic workloads for broader design-space exploration.
In our experimentswe used parameters similar to those in related work [15, 25, 26,38, 49, 50] (see Table 3). We considered M ∈ { , } cores and eachtaskset instance contained [ × M , × M ] RT and [ × M , × M ] security tasks. To generate tasksets with an even distribution oftasks, we grouped the real-time and security tasksets by base-utilization from [( . + . i ) M , ( . + . i ) M ] where i ∈ Z , ≤ generic framework proposed in this paper allows the designers to accommodate anydesired security ( e.g., intrusion detection/prevention) technique. Utilization (Normalized) D i s t an c e f r o mM a x i m u m P e r i od ( N o r m a li z ed ) [ . , . ][ . , . ][ . , . ][ . , . ][ . , . ][ . , . ][ . , . ][ . , . ][ . , . ][ . , . ] [ . , . ][ . , . ][ . , . ][ . , . ][ . , . ][ . , . ][ . , . ][ . , . ][ . , . ][ . , . ] Figure 6: Euclidean distance between achievable period andmaximum period vectors for different utilizations. Largerdistance (y-axis in the figure) implies security tasks executemore frequently. i ≤
9. Each utilization group contained 250 tasksets ( e.g., total10 × = e.g., the conditionin Section 2.1 was satisfied for all RT tasks) – since tasksets thatfail to meet this condition are trivially unschedulable. Task periodswere generated according to a log-uniform distribution. Each RTtask had periods between [ , ] ms and the maximum periodsfor security tasks were selected from [ , ] ms. We assumedthat RT tasks were partitioned using a best-fit [1] strategy andthe total utilization of the security tasks was at least 30% of thesystem utilization. For a given number of tasks and total systemutilization, the utilization of individual tasks were generated usingRandfixedsum algorithm [51]. We first observe howfrequently we can execute (schedule) security tasks compared tothe designer specified bound (Fig. 6). The x-axis of Fig. 6 showsthe normalized utilization UM where U is the minimum utilizationrequirement and given as follows: U = (cid:205) τ r ∈ Γ R C r T r + (cid:205) τ s ∈ Γ S C s T maxs . They-axis represents the Euclidean distance between the calculatedperiod vector T ∗ = [ T ∗ s ] ∀ τ s ∈ Γ S and maximum period vector T max = [ T maxs ] ∀ τ s ∈ Γ S (normalized to 1). A higher distance implies thattasks can run more frequently. As we can see from the figure forhigher utilizations, the distance reduces ( e.g., periods are closer tothe maximum value) – this is mainly due to the interference fromhigher priority (RT and security) tasks. The results from this figuresuggest that we can execute security tasks more frequently for lowto medium utilization cases. While inthis work we consider a legacy RT system ( i.e., where RT tasksare partitioned to respective cores), for comparison purposes weconsidered the following two schemes (in addition to the relatedwork, HYDRA, introduced in Section 5.1) that do not consider anyperiod adaptation for security tasks. • GLOBAL-TMax: In this scheme all the RT and securitytasks are scheduled using a global fixed-priority multicorescheduling scheme [30]. Since our focus here is onschedulability we set T s = T maxs , ∀ τ s ∈ Γ S (recall thata taskset can be considered schedulable if the followingconditions hold: R r ≤ D r , ∀ τ r ∈ Γ R and R s ≤ T maxs , ∀ τ s ∈ Γ S ). This scheme allows us to observe the performance .0 0.2 0.4 0.6 0.8 1.0 Utilization (Normalized) A cc ep t an c e R a t i o ( % ) [ . , . ][ . , . ][ . , . ][ . , . ][ . , . ][ . , . ][ . , . ][ . , . ][ . , . ][ . , . ] HYDRA-C HYDRA GLOBAL-TMax HYDRA-TMax [ . , . ][ . , . ][ . , . ][ . , . ][ . , . ][ . , . ][ . , . ][ . , . ][ . , . ][ . , . ] (a) Utilization (Normalized) N o r m a li z ed D i ff e r en c e i n P e r i od V e c t o r [ . , . ][ . , . ][ . , . ][ . , . ][ . , . ][ . , . ][ . , . ][ . , . ][ . , . ][ . , . ] HYDRA-C vs HYDRA HYDRA-C vs w/o Period Optimization [ . , . ][ . , . ][ . , . ][ . , . ][ . , . ][ . , . ][ . , . ][ . , . ][ . , . ][ . , . ] (b) Figure 7: Impact on schedulability and security. (a)
The acceptance ratio vs taskset utilizations for 2 and 4 core platforms: ourscheme outperforms HYDRA and GLOBAL-TMax approaches for higher utilizations. (b)
Difference in period vectors for ourapproach and reference schemes ( e.g.,
HYDRA, GLOBAL-TMax, HYDRA-TMax): the non-negative distance (y-axis in the figure)implies that HYDRA-C finds shorter periods than other schemes. impacts of binding RT tasks to the cores (due to legacycompatibility). • HYDRA-TMax: This is similar to the HYDRA approachintroduced in Section 5.1 ( i.e., security tasks were partitionedusing best-fit allocation as before) but instead of minimizingperiods here we set T s = T maxs , ∀ τ s . This allows us toobserve the trade-offs between schedulability and securityin a fully-partitioned system.In Fig. 7a we compare the performance of HYDRA-C with theHYDRA, GLOBAL-TMax and HYDRA-TMax strategies in termsof acceptance ratio (y-axis in the figure) defined as the numberof schedulable tasksets ( e.g., R s ≤ T maxs , ∀ τ s ) over the generatedone and the x-axis shows the normalized utilization UM . As wecan see from the figure, HYDRA-C outperforms HYDRA when theutilization increases ( i.e., UM > . i.e., UM ≥ .
7) HYDRA-C can find tasksets schedulablethat can not be easily partitioned by using the HYDRA-TMaxscheme. The acceptance ratio of our method and the HYDRA-TMax scheme is equal when UM < .
7. This is because, for lowerutilizations some lower priority security tasks experience lessinterference due to longer periods and specific core assignment(recall we set T s = T maxs for all security tasks). While we bindthe RT tasks to cores (due to legacy compatibility), it does notaffect the schedulability ( i.e., the acceptance ratio of HYDRA-Cis higher when compared to the GLOBAL-TMax scheme). This isbecause, RT tasks are already schedulable when partitioned ( e.g., by assumption on taskset generation, see Section 5.2.1) and ouranalysis reduces the interference that RT tasks have on securityones. For higher utilizations, the acceptance ratio drops for all theschemes since it is not possible to satisfy all the constraints due to the high interference from RT and security tasks. We also highlightthat while our approach results in better schedulability, HYDRA-C/HYDRA-TMax ( i.e., where legacy RT tasks are partitioned tothe cores) and GLOBAL-TMax ( i.e., where all tasks can migrate)schemes are incomparable in general ( e.g., there exists taskset thatmay be schedulable by task partitioning but not in global schemewhere migration is allowed and vice-versa) – we allow securitytasks to migrate due to security requirements ( e.g., to achieve fasterintrusion detection – as we explain in the next experiments, seeFig. 7b).In the final set of experiments (Fig. 7b) we compare the achievableperiods (in terms of Euclidean distance) for our approach and theother schemes. The x-axis in the Fig. 7b shows the normalizedutilizations and the y-axis represents the average differencebetween the following period vectors: (a) between HYDRA-C andHYDRA (dashed line); (b) HYDRA-C and other strategies ( e.g.,
GLOBAL-TMax and HYDRA-TMax) that do not consider periodminimization (dotted marker) for dual and quad core setup. Higherdistance values imply that the periods calculated by HYDRA-Care smaller ( i.e., leads to faster detection time) and our approachoutperforms the other scheme. For low to medium utilizations( e.g., . ≤ U ≤ .
5) HYDRA-C performs better when compared toHYDRA. In situations with higher utilizations, the lesser availabilityof slack time results in HYDRA-C and HYDRA performing in asimilar manner. Also, for higher utilizations HYDRA is unable tofind schedulable tasksets and hence there exist fewer data points.Our experiments also show that compared to GLOBAL-TMaxand HYDRA-TMax our approach finds smaller periods in most cases(Fig. 7b). This is expected since there is no period adaptation ( i.e., we set T s = T maxs for those schemes). However it is importantto note that HYDRA-C achieves better execution frequency ( i.e., smaller periods) without sacrificing schedulability as seen in Fig. 7a.That is, our semi-partitioned approach achieves better continuousmonitoring when compared with both a fully-partitioned approach(HYDRA, HYDRA-TMax) and a global scheduling approach(GLOBAL-TMax) while providing the same or better schedulability. DISCUSSION
In this paper we do not design for any specific security tasks (theIDS system used is meant for demonstration purposes only) andallow designers to integrate their preferred techniques. Dependingon the actual implementation of the security tasks some attackmay not be detectable. For instance, the system may be vulnerableto zero-day attacks if the security tasks are not designed todetect unforeseen exploits or anomalous behaviors. There existscases where security tasks may require some amount of systemmodifications and/or porting efforts – say a timing behavior basedsecurity checking [11, 28, 52] may require the insertion of probingmechanisms inside the RT application tasks (or additional hardware)so that security tasks can validate their expected execution profiles.HYDRA-C abstracts security tasks (and underlying monitoringevents) and works in a proactive manner. However, designers maywant to integrate security tasks that react , based on anomalousbehavior. For instance, let at time t , j -th job of task τ s ( e.g., τ js )performs action a ( e.g., runtime of real-time tasks). Because ofintrusions (or perhaps due to other system artifacts) in time [ t , t + T s ] ( T s is the period of τ s ), job τ j + s finds that a is not behaving asexpected. Therefore τ j + s may perform both actions, a and a (saythat checks the list of system calls, to see if any undesired callsare executed). One way to support such a feature is to considerthe dependency ( i.e., a depends on a in this case) betweensecurity checks ( e.g., sub-tasks). We intend to extend our frameworkconsidering dependency between security tasks. RT Scheduling and Period Optimization.
Although not in thecontext of RT security, the scheduling approaches present in thispaper can be considered as a special case of prior work [53] whereeach task can bind to any arbitrary number of available cores.For a given period, this prior analysis [53] is pessimistic for themodel considered by HYDRA-C ( i.e.,
RT tasks are partitioned andsecurity tasks can migrate on any core) in a sense that it over-approximates carry-in interference from the tasks bound to singlecores ( e.g.,
RT tasks) and hence results in lower schedulability ( e.g., identical to the GLOBAL-TMax scheme in Fig. 7a). Researchers alsopropose various semi-partitioned scheduling strategies for fixed-priority RTS [35, 54]. However, this work primarily focuses onimproving schedulability ( e.g., by allowing highest priority taskto migrate) and they are not designed for security requirementsin consideration ( e.g., minimizing periods and executing securitytasks with fewer interruption for faster anomaly detection). Thereexists other work [55] in which the authors statically assign theperiods for multiple independent control tasks considering controldelay as a cost metric. Davare et al. [56] propose to assign task andmessage periods as well as satisfy end-to-end latency constraintsfor distributed automotive systems. While the previous work focuson optimizing period of all the tasks in the system for a singlecore setup, our goal is to ensure security without violating timingconstraints of the RT tasks in a multicore platform.
Security Solutions for RTS.
In recent years researchers proposedvarious mechanisms to provide security guarantees into legacyand non-legacy RTS (both single and multicore platforms) in several directions, viz., integration of security mechanisms [25–27], authenticating/encrypting communication channels [7–10,14, 57], side-channel defence techniques [15, 58–61] as well ashardware/software-based frameworks [11–13, 62–65].Perhaps the closest line of research is HYDRA [26] where authorsproposed to statically partition security tasks to the cores andused an optimization-based solution to obtain the periods. Whilethis approach does not have the overhead of context switchesacross cores, as we observed from our experiments (Section 5),that scheme results in a poor acceptance ratio for larger utilizations,and suffers interference from other high priority tasks leading toslower detection of intrusions ( i.e., less effective). The problemof integrating security for single core RTS is addressed in priorresearch [25] where authors used hierarchical scheduling [66] andproposed to execute security tasks with a low priority server. Thisapproach is also extended to a multi-mode framework [27] thatallows security tasks to execute in different modes ( i.e., passivemonitoring with lowest priority as well as exhaustive checkingwith higher priority). These server-based approaches, however,may require additional porting efforts for legacy systems.There exists recent work [9, 10] to secure cyber-physicalsystems from man-in-the-middle attacks by enabling authenticationmechanisms and timing-aware network resource scheduling.There has also been work [7, 8, 14] where authors proposedto add protective security mechanisms into RTS and consideredperiodic task scheduling where each task requires a securityservice whose overhead varies according to the required levelof service. The problem of designing secure multi-mode RTShave also been addressed in prior work [57] under dynamic-priority scheduling. In contrast, we consider a multicore fixed-priority scheduling mechanism where security tasks are executedperiodically, across cores, while meeting real-time requirements.The above mentioned work are designed for single core platformsand it is not straightforward to retrofit those approaches formulticore legacy systems.In another direction, the issues related to information leakagethrough storage timing channels using shared architecturalresources ( e.g., caches) is introduced in prior work [15, 58, 59]. Thekey idea is to use a modified fixed-priority scheduling algorithmwith a state cleanup mechanism to mitigate information leakagethrough shared resources. However, this leakage prevention comesat a cost of reduced schedulability. Researchers also proposed tolimit inferability of deterministic RT schedulers by randomizingthe task execution patterns. Yoon et al. [60] proposed a scheduleobfuscation method for fixed-priority RM systems. A combinedonline/offline randomization scheme [61] is also proposed to reducedeterminism for time-triggered (TT) systems where tasks areexecuted based on a pre-computed, offline, slot-based schedule.We highlight that all the aforementioned work either requiresmodification to the scheduler or RT task parameters, and is designedfor single core systems only.Unlike our approach that works at the scheduler-level,researchers also proposed hardware/software-based architecturalsolutions [11–13, 62–65, 67] to improve the security posture offuture RTS. Those solutions require system-level modificationsand are not suitable for legacy systems. To our knowledge this s the first work that aims to achieve continuous monitoring formulticore-based legacy RT platforms. Threats to safety-critical RTS are growing and there is a needfor developing layered defense mechanisms to secure suchcritical systems. We present algorithms to integrate continuoussecurity monitoring for legacy multicore-based RTS. By using ourframework, systems engineers can improve the security postureof RTS. This additional security guarantee also enhances safety –which is the main goal for such systems.
REFERENCES [1] J. Chen, “Partitioned multiprocessor fixed-priority scheduling of sporadic real-time tasks,” in
Euromicro ECRTS , 2016, pp. 251–261.[2] N. Falliere, L. O. Murchu, and E. Chien, “W32. stuxnet dossier,”
White paper,Symantec Corp., Security Response , vol. 5, p. 6, 2011.[3] R. M. Lee, M. J. Assante, and T. Conway, “Analysis of the cyber attack on theukrainian power grid,”
SANS Industrial Control Systems , 2016.[4] K. Koscher, A. Czeskis, F. Roesner, S. Patel, T. Kohno, S. Checkoway, D. McCoy,B. Kantor, D. Anderson, H. Shacham et al. , “Experimental security analysis of amodern automobile,” in
IEEE S&P , 2010, pp. 447–462.[5] S. Checkoway, D. McCoy, B. Kantor, D. Anderson, H. Shacham, S. Savage,K. Koscher, A. Czeskis, F. Roesner, T. Kohno et al. , “Comprehensive experimentalanalyses of automotive attack surfaces,” in
USENIX Sec. Symp. , 2011.[6] S. S. Clark and K. Fu, “Recent results in computer security for medical devices,”in
MobiHealth , 2011, pp. 111–118.[7] T. Xie and X. Qin, “Improving security for periodic tasks in embedded systemsthrough scheduling,”
ACM TECS , vol. 6, no. 3, p. 20, 2007.[8] M. Lin, L. Xu, L. T. Yang, X. Qin, N. Zheng, Z. Wu, and M. Qiu, “Static securityoptimization for real-time systems,”
IEEE Trans. on Indust. Info. , vol. 5, no. 1, pp.22–37, 2009.[9] V. Lesi, I. Jovanov, and M. Pajic, “Network scheduling for secure cyber-physicalsystems,” in
IEEE RTSS , 2017, pp. 45–55.[10] V. Lesi, I. Jovanov, and M. Pajic, “Security-aware scheduling of embedded controltasks,”
ACM TECS , vol. 16, pp. 188:1–188:21, 2017.[11] M.-K. Yoon, S. Mohan, J. Choi, J.-E. Kim, and L. Sha, “SecureCore: A multicore-based intrusion detection architecture for real-time embedded systems,” in
IEEERTAS , 2013, pp. 21–32.[12] M.-K. Yoon, S. Mohan, J. Choi, and L. Sha, “Memory heat map: anomaly detectionin real-time embedded systems using memory behavior,” in
ACM/EDAC/IEEEDAC , 2015, pp. 1–6.[13] M.-K. Yoon, S. Mohan, J. Choi, M. Christodorescu, and L. Sha, “Learning executioncontexts from system call distribution for anomaly detection in smart embeddedsystem,” in
ACM/IEEE IoTDI , 2017, pp. 191–196.[14] T. Xie, A. Sung, and X. Qin, “Dynamic task scheduling with security awarenessin real-time systems,” in
Parallel and Distributed Processing Symposium, 2005.Proceedings. 19th IEEE International . IEEE, 2005, pp. 8–pp.[15] S. Mohan, M.-K. Yoon, R. Pellizzoni, and R. B. Bobba, “Integrating securityconstraints into fixed priority real-time schedulers,”
RTS Journal , vol. 52, no. 5,pp. 644–674, 2016.[16] S. Mohan, “Worst-case execution time analysis of security policies for deeplyembedded real-time systems,”
ACM SIGBED Review
USENIXConf. on Sys. Admin. , 1999, pp. 229–238.[21] L. L. Woo, M. Zwolinski, and B. Halak, “Early detection of system-level anomalousbehaviour using hardware performance counters,” in
DATE , 2018, pp. 485–490.[22] V. M. Weaver, “Linux perf_event features and overhead,” in
IEEE FastPath , 2013.[23] “OProfile,” http://oprofile.sourceforge.net/.[24] V. Chandola, A. Banerjee, and V. Kumar, “Anomaly detection: A survey,”
ACMCSUR , vol. 41, no. 3, p. 15, 2009.[25] M. Hasan, S. Mohan, R. B. Bobba, and R. Pellizzoni, “Exploring opportunisticexecution for integrating security into legacy hard real-time systems,” in
IEEERTSS , 2016, pp. 123–134.[26] M. Hasan, S. Mohan, R. Pellizzoni, and R. B. Bobba, “A design-space explorationfor allocating security tasks in multicore real-time systems,” in
DATE , 2018, pp.225–230.[27] M. Hasan, S. Mohan, R. Pellizzoni, and R. B. Bobba, “Contego: An adaptive framework for integrating security tasks in real-time systems,” in
EuromicroECRTS , 2017, pp. 23:1–23:22.[28] M. Hamad, Z. A. Hammadeh, S. Saidi, V. Prevelakis, and R. Ernst, “Predictionof abnormal temporal behavior in real-time systems,” in
ACM SAC , 2018, pp.359–367.[29] L. Sha, M. Caccamo, R. Mancuso, J.-E. Kim, M.-K. Yoon, R. Pellizzoni, H. Yun, R. B.Kegley, D. R. Perlman, G. Arundale et al. , “Real-time computing on multicoreprocessors,”
IEEE Comp. , vol. 49, no. 9, pp. 69–77, 2016.[30] R. I. Davis and A. Burns, “A survey of hard real-time scheduling for multiprocessorsystems,”
ACM Comput. Surv. , vol. 43, no. 4, pp. 35:1–35:44, 2011.[31] C.-Y. Chen, M. Hasan, and S. Mohan, “Securing real-time Internet-of-things,”
Sensors , vol. 18, no. 12, 2018.[32] G. Heiser and B. Leslie, “The okl4 microvisor: Convergence point of microkernelsand hypervisors,” in
ACM APSys . ACM, 2010, pp. 19–24.[33] F. Kolnick, “The qnx 4 real-time operating system,”
Basis Comp. Sys. Inc. , 1998.[34] L. Fu and R. Schwebel, “Real-time Linux wiki,” https://rt.wiki.kernel.org/index.php/rt_preempt_howto, [Online].[35] S. Kato and N. Yamasaki, “Semi-partitioned fixed-priority scheduling onmultiprocessors,” in
IEEE RTAS , 2009, pp. 23–32.[36] C. L. Liu and J. W. Layland, “Scheduling algorithms for multiprogramming in ahard-real-time environment,”
JACM , vol. 20, no. 1, pp. 46–61, 1973.[37] N. Guan, M. Stigge, W. Yi, and G. Yu, “New response time bounds for fixed prioritymultiprocessor scheduling,” in
IEEE RTSS , 2009, pp. 387–397.[38] Y. Sun, G. Lipari, N. Guan, and W. Yi, “Improving the response time analysis ofglobal fixed-priority multiprocessor scheduling,” in
IEEE RTCSA , 2014, pp. 1–9.[39] S. Baruah, “Techniques for multiprocessor global schedulability analysis,” in
IEEERTSS , 2007, pp. 119–128.[40] M. Bertogna and M. Cirinei, “Response-time analysis for globally scheduledsymmetric multiprocessor platforms,” in
IEEE RTSS , 2007, pp. 149–160.[41] D. E. Knuth,
The art of computer programming: sorting and searching
ACM TECS , vol. 14, no. 3, pp. 47:1–47:28, 2015.[50] M.-K. Yoon, J.-E. Kim, R. Bradford, and L. Sha, “Holistic design parameteroptimization of multiple periodic resources in hierarchical scheduling,” in
DATE ,2013, pp. 1313–1318.[51] P. Emberson, R. Stafford, and R. I. Davis, “Techniques for the synthesis ofmultiprocessor tasksets,” in
WATERS , 2010, pp. 6–11.[52] M.-K. Yoon, M. Christodorescu, L. Sha, and S. Mohan, “The dragonbeamframework: Hardware-protected security modules for in-place intrusiondetection,” in
ACM SYSTOR , 2016, pp. 1:1–1:12.[53] A. Gujarati, F. Cerqueira, and B. B. Brandenburg, “Schedulability analysis of theLinux push and pull scheduler with arbitrary processor affinities,” in
EuromicroECRTS , 2013, pp. 69–79.[54] K. Lakshmanan, R. Rajkumar, and J. Lehoczky, “Partitioned fixed-prioritypreemptive scheduling for multi-core processors,” in
Euromicro ECRTS , 2009,pp. 239–248.[55] E. Bini and A. Cervin, “Delay-aware period assignment in control systems,” in
IEEE RTSS , 2008, pp. 291–300.[56] A. Davare, Q. Zhu, M. Di Natale, C. Pinello, S. Kanajan, and A. Sangiovanni-Vincentelli, “Period optimization for hard real-time distributed automotivesystems,” in
ACM DAC , 2007, pp. 278–283.[57] K. Jiang, P. Eles, and Z. Peng, “Optimization of secure embedded systems withdynamic task sets,” in
DATE , 2013, pp. 1765–1770.[58] S. Mohan, M.-K. Yoon, R. Pellizzoni, and R. B. Bobba, “Real-time systems securitythrough scheduler constraints,” in
Euromicro ECRTS , 2014, pp. 129–140.[59] R. Pellizzoni, N. Paryab, M.-K. Yoon, S. Bak, S. Mohan, and R. B. Bobba, “Ageneralized model for preventing information leakage in hard real-time systems,”in
IEEE RTAS , 2015, pp. 271–282.[60] M.-K. Yoon, S. Mohan, C.-Y. Chen, and L. Sha, “TaskShuffler: A schedulerandomization protocol for obfuscation against timing inference attacks in real-time systems,” in
IEEE RTAS , 2016, pp. 1–12.[61] K. Krüger, M. Völp, and G. Fohler, “Vulnerability analysis and mitigationof directed timing inference based attacks on time-triggered systems,” in
EUROMICRO ECRTS , vol. 106, 2018, pp. 22:1–22:17.[62] S. Mohan, S. Bak, E. Betti, H. Yun, L. Sha, and M. Caccamo, “S3A: Secure systemsimplex architecture for enhanced security and robustness of cyber-physicalsystems,” in
ACM international conference on High confidence networked systems .ACM, 2013, pp. 65–74.
63] D. Lo, M. Ismail, T. Chen, and G. E. Suh, “Slack-aware opportunistic monitoringfor real-time systems,” in
IEEE RTAS , 2014, pp. 203–214.[64] F. Abdi, M. Hasan, S. Mohan, D. Agarwal, and M. Caccamo, “ReSecure: A restart-based security protocol for tightly actuated hard real-time systems,” in
IEEECERTS , 2016, pp. 47–54.[65] F. Abdi, C.-Y. Chen, M. Hasan, S. Liu, S. Mohan, and M. Caccamo, “Guaranteedphysical security with restart-based design for cyber-physical systems,” in
ACM/IEEE ICCPS , 2018, pp. 10–21.[66] R. Davis and A. Burns, “An investigation into server parameter selection forhierarchical fixed priority pre-emptive systems,” in
IEEE RTNS , 2008.[67] F. Abdi, J. Woude, Y. Lu, S. Bak, M. Caccamo, L. Sha, R. Mancuso, and S. Mohan,“On-chip control flow integrity check for real time embedded systems,” in
IEEECPSNA , 2013, pp. 26–31., 2013, pp. 26–31.