Limited resources in terms of processing power, memory, energy, etc. coupled with the fact that security was not considered a design priority 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 security solutions is a challenging problem since any perturbation of the real-time (RT) constraints (runtimes, periods, task execution orders, deadlines, etc.) could be detrimental to the correct and safe operation of RTS. Besides, security mechanisms need to be designed in such a way that an adversary can not easily evade them. Successful attacks/intrusions into RTS are often aimed at impacting the safety guarantees of such systems, as evidenced by recent intrusions (e.g., attacks on control systems (stuxnet; Ukraine16), automobiles (ris_rts_1; checkoway2011comprehensive), medical devices (security_medical), etc. to name but a few). Systems with RT properties pose unique security challenges – these systems are required to meet stringent timing requirements along with strong safety requirements. Limited resources (i.e., computational power, storage, energy, etc.) prevent security mechanisms that have been primarily developed for general purpose systems from being effective for safety-critical RTS. In this paper we aim to improve the security posture of RTS through integration of security tasks while ensuring that the existing RT tasks are not affected by such integration. The security tasks considered could be carrying out any one of protection, detection or response-based operations, depending on the system requirements. For instance, a sensor measurement correlation task may be added for detecting sensor manipulation or a change detection task (or other intrusion detection programs) may be added to detect changes/intrusions into the system. In Table 1 we present some examples of security tasks that can be integrated into legacy 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.) may require modification of the system or the RT task parameters as was the case in prior work (xie2007improving; lin2009static; lesi2017network; lesi2017security; securecore; securecore_memory; securecore_syscal; xie2005dynamic; sibin_RT_security_journal). Further, to provide the best protection, security tasks may need to be executed as often as possible. If the interval between consecutive checking events is too large then an attacker may remain undetected and cause harm to the system between two invocations of the security task. In contrast, if the security tasks are executed very frequently, it may impact the schedulability of the RT (and other security) tasks. The challenge is then to determining the right periods (i.e., minimum inter-invocation time) for the security tasks (sibin_deeply).
|File-system checking||Tripwire (tripwire), AIDE (aide), etc.|
|Network packet monitoring||Bro (bro), Snort (snort), etc.|
|Hardware event monitoring||Statistical analysis based checks (woo2018early) using performance monitors (e.g., perf (linux_perf), OProfile (oprofile), etc.)|
|Application specific checking||Behavior-based detection (see the related work (anomaly_detection_survey; securecore; securecore_memory; securecore_syscal))|
As a step towards enabling the design of secure RT platforms, opportunistic execution (mhasan_rtss16; mhasan_date18) has been proposed as a potential way to integrate security mechanisms into legacy RTS – this allows the execution of security mechanisms as background services without impacting the timing constraints of the RT tasks. Other approaches have been built on this technique for integrating tasks into both legacy and non-legacy systems (mhasan_ecrts17; xie2007improving; lin2009static; lesi2017network; lesi2017security; securecore; hamad2018prediction). However, most of that work was focused on single core RTS (that are a majority of such systems in use today). However, multicore processors have found increased use in the design of RTS to improve overall performance and energy efficiency (rt_multicore_lui; mutiprocessor_survey). While the use of such processors increases the security problems in RTS (e.g., due to parallel execution of critical tasks) (mhasan_rtiot_sensors19) to our knowledge very few security solutions have been proposed in literature (mhasan_date18). In prior work (called HYDRA) (mhasan_date18) researchers have developed a mechanism for integrating security into multicore RTS. However this work uses a partitioned scheduling approach and does not allow runtime migration of security tasks across cores. We show that this results in delayed detection of intrusions222We discuss this issue further in Section 5. as the security tasks are not able to execute as frequently. Our main goal in this paper is to raise the responsiveness of such security tasks by increasing their frequency of execution. For instance, consider an intrusion detection system (IDS) – say one that checks the integrity of file systems. If such a system is interrupted (before it can complete checking the entire system), then an adversary could use that opportunity to intrude into the system and, perhaps, stay resident in the part of the filesystem that has already been checked (assuming that the IDS is carrying out the check in parts). If, on the other hand, the IDS task 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.
In this paper, we propose a design-time methodology and a framework named HYDRA-C for partitioned333Since this is the commonly used multicore scheduling approach for many commercial and open-source OSs (such as OKL4 (okl4), QNX (qnx), RT-Linux (rt_patch), etc.) – mainly due to its simplicity and efficiency (parti_see; mhasan_date18). RTS that (a) leverages semi-partitioned scheduling (kato2009semi) to enable continuous execution of security tasks (i.e., execute as frequently as possible) across cores, and (b) does not impact the timing constraints of other, existing, RT tasks. HYDRA-C takes advantage of the properties of a multicore platform and allows security tasks to migrate across available cores and execute opportunistically (i.e., when the RT tasks are not running). This framework extends existing work (mhasan_date18) and ensures better security (e.g., faster detection time) and schedulability (see Section 5). HYDRA-C is able to do this without violating timing constraints for either the existing RT tasks or the security ones (Section 3). We develop a mathematical model and iterative solution that allows security tasks to execute as frequently as possible while still considering the schedulability constraints of other tasks (Section 4). In addition, we also present an implementation on a realistic ARM-based multicore rover platform (running a RT variant of Linux system and realistic security applications). We then perform comparisons with the state-of-the-art (mhasan_date18) (Section 5.1). Finally, we carry out a design space exploration using synthetic workloads and study trade-offs for schedulability and security. Our evaluation shows that proposed semi-partitioned approach can achieve better execution frequency for security tasks and consequently quicker intrusion detection ( faster on average) when compared with both fully-partitioned and global scheduling approaches while providing the same or better schedulability (Section 5.2). Note: We do not target our framework towards any specific security mechanism – our focus is to integrate any designer-provided security solution into a multicore-based RTS. In our experiments we used Tripwire (tripwire) (a data integrity checking tool) as well as our in-house custom-developed malicious kernel module checker to demonstrate the feasibility of our approach – the integration framework proposed in this paper is more broadly applicable to other security mechanisms.
2. Model and Assumptions
2.1. Real-time Tasks and Scheduling Model
Consider a set of RT tasks , scheduled on a multicore platform with identical cores . Each RT task releases an infinite sequence of task instances, also called jobs, and is represented by the tuple where is the worst-case execution time (WCET), is the minimum inter-arrival time (e.g., period) and is the relative deadline. The utilization of each task is denoted by . We assume constrained deadlines for RT tasks (e.g., ) and that the task priorities are assigned according to rate-monotonic (RM) (Liu_n_Layland1973) order (e.g., shorter period implies higher priority). All events in the system happen with the precision of integer clock ticks (i.e., processor clock cycles), that is, any time involved in scheduling is a non-negative integer. In this paper we consider RT tasks that are scheduled using partitioned fixed-priority preemptive scheme (mutiprocessor_survey) and assigned to the cores using a standard task partitioning algorithm (parti_see; mutiprocessor_survey). We further assume that the RT tasks are schedulable, viz., the worst-case response time (WCRT), denoted as , is less than deadline (e.g., ) and the following necessary and sufficient schedulability condition holds for each RT tasks assigned to any given core (parti_see):
where denotes the set of RT tasks with higher priority than assigned to core .
2.2. Security Model
Our focus is on integrating given security mechanisms abstracted as security tasks into a legacy multicore RTS without impacting the RT functionality of the RTS. While we use specific intrusion detection mechanisms (e.g., Tripwire) to demonstrate our approach, our approach is somewhat agnostic to the security mechanisms. The security model used and the design of security tasks are orthogonal problems. Since we aim to maximize the frequency of execution of security tasks, security mechanisms whose performance improves with frequency of execution (e.g., intrusion monitoring and detection tasks) benefit from our framework.
3. Security Integration Framework
We propose to improve the security posture of multicore based RT systems by integrating additional periodic security tasks (e.g., tasks that are specifically designed for intrusion detection purposes). We highlight that HYDRA-C abstracts security tasks and allows designers to execute any given techniques. Our focus here is on integration of a given set of security tasks (e.g., intrusion detection mechanisms) in an existing multicore RTS without impacting the RT task parameters (e.g., WCET, periods, etc.) or their task execution order. In general, the addition of security mechanisms may increase the execution time of existing tasks (lin2009static; xie2007improving) or reduce schedulability (sibin_RT_security_journal). As we mentioned earlier, our focus is on legacy multicore systems where designers may not have enough flexibility to modify system parameters to integrate security mechanisms. We address this problem by allowing security tasks to execute with a priority lower than all the RT tasks, i.e., leverage opportunistic execution (mhasan_rtss16; mhasan_date18). This way, security tasks will only execute during the slack time (e.g., when a core is idle) and the timing requirements of the RT tasks will not be perturbed. However, in contrast to prior work (HYDRA) (mhasan_date18) where the security tasks are statically bound to their respective cores, in this paper we allow security tasks to continuously migrate at runtime (i.e., the combined taskset with RT 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 blue and green rectangles) are partitioned into two cores and a newly added security task (red rectangle) can move across cores.
As we shall see in Section 5, allowing security tasks to execute on any available core will give us the opportunity to execute security tasks more frequently (e.g., with shorter period) and that leads to better responsiveness (faster intrusion detection time). One fundamental question with our security integration approach is to figure out how often to execute security tasks so that the system remains schedulable (e.g., WCRT is less than period), and also can execute within a designer provided frequency bound (so that the security checking remains effective). This is different when compared to scheduling traditional RT tasks since the RT task parameters (e.g., periods) are often derived from physical system properties and cannot be adjusted due to control/application requirements. We now formally define security tasks.
Let us include a set of security tasks in the system. We adopt the periodic security task model (mhasan_rtss16) and represent each security task by the tuple where is the WCET, is the (unknown) period (e.g., is the monitoring frequency) and is a designer provided upper bound of the period – if the period of the security task is higher than then the responsiveness is too low and security checking may not be effective. We assume that priority of the security tasks are distinct and specified by the designers (e.g., derived from specific security requirements). Security tasks have implicit deadlines, i.e., they need to finish execution before the next invocation. We also assume that task migration and context switch overhead is negligible compared to WCET of the task. Our goal here is to find a minimum period (so that the security tasks can execute more frequently) such that the taskset remains schedulable (e.g., : where is the WCRT444The calculation of WCRT is presented in Section 4.4. of ).
4. Period Selection
The actual periods for the security tasks are not known – we need to find the periods that ensures schedulability and gives us better monitoring frequency. Mathematically this can be expressed as the following optimization problem: , subject to . This is a non-trivial problem since the period of can be anything in and the response time is variable as it depends on the period of other higher priority security tasks. We first derive the WCRT of the security tasks and use it as a (lower) bound to find the periods. Our WCRT calculation for security tasks is based on the existing iterative analysis for global multicore scheduling (guan2009new_wcrt_bound; sun2014improving_wcrt2; global_rta_sanjay) and we modify it to account the fact that RT tasks are partitioned.
We start by briefly reviewing the relevant terminology and parameters. We are interested in determining the response time of a job of task (e.g., job under analysis) using an iterative method and the response time in each iteration is denoted by .
Definition 0 (Busy Period).
The busy period of is the maximal continuous time interval (until finishes) where all the cores are executing either higher priority tasks or itself.
Definition 0 (Interference).
Given task , the interference caused by on is the number of time units in the busy period when executes while does not.
Note that the job under analysis cannot execute if all cores are busy with higher priority tasks; hence, the length of the busy period is at most by definition, where is the sum of the interference caused by all higher priority tasks on . To compute the value of , we rely on the concept of workload.
Definition 0 (Workload).
The workload of a task in a window of length represents the accumulated execution time of within this time interval.
It remains to compute the workload and corresponding interference for each higher priority task . We first show how to do so for RT tasks and then for security tasks with higher priority than .
4.2. Interference Calculation for RT Tasks
Since RT tasks are statically partitioned to cores and they have higher priority than any task that is allowed to migrate between cores, the worst-case workload for RT tasks can be trivially obtained based on the same critical instant used for single core fixed-priority scheduling case (Liu_n_Layland1973).
Lemma 4 ().
For a given core , the maximum workload of RT tasks executed on in any possible time interval of length is obtained when all RT tasks are released synchronously at the beginning of the interval.
Since RT tasks are partitioned and they have higher priorities than security tasks, the schedule of RT tasks executed on does not depend on any other task in the system. Now consider any interval of length . We show that we can obtain an interval where all tasks are released at , such that the workload of RT tasks on is higher in compared to . First step: let be the earliest time such that continuously executes RT tasks in ; if such time does not exist, then let . By definition, does not execute RT tasks at time . Also since RT tasks continuously execute in , the workload of RT tasks in cannot be smaller than the workload in . Second step: since is idle at , no job of RT tasks on released before can contribute to the workload in . Hence, the workload can be maximized by anticipating the release of each RT task so that it corresponds with . This concludes the proof. ∎
Let denote the set of RT tasks partitioned to core . Based on Lemma 4, an upper bound to the workload of RT tasks on can be obtained by assuming that each RT task is released at the beginning of the interval and each job of executes as early as possible after being released, as shown in Fig. 2. We thus obtain the workload for RT task :
and summing over all RT tasks on yields a total workload . Finally, we notice that by definition the interference caused by a group of tasks executing on the same core on cannot be greater than . Therefore, the maximum interference caused by RT tasks on to can be bounded as:
The ‘’ 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 time is denoted by ) to the correct value (bertogna2007response). For example, when the iterative search for the response time is started with (i.e., ), the search would stop immediately (and outputs an incorrect WCRT) since .
4.3. Interference Calculation for Security Tasks
We next consider the workload of security tasks with higher priority than . The workload computation depends on the arrival time of the task relative to the beginning of the busy period, as specified in the following definition.
Definition 0 (Carry-in).
A task is called a carry-in task if there exists one job of that has been released before the beginning of a given time window of length and executes within the window. If no such job exists, is referred to as a non-carry-in task.
Generally (but not always), the workload of a task in the busy period is higher if is a carry-in task than a non-carry-in task. Hence, it is important to limit the number of higher priority carry-in tasks. To this end, we follow an approach similar to prior research (guan2009new_wcrt_bound; global_rta_sanjay) and extend the busy period of from its arrival time (denoted by ) to an earlier time instance (see Fig. 3) such that during any time instance all cores are busy executing tasks with higher priority than . Note that by definition, this implies that there was at least one free core (i.e., not executing higher priority tasks) at time .
Lemma 2 ().
At most higher priority tasks can have carry-in at time .
The maximum number of higher priority tasks that can have carry-in at is since by definition there have to be strictly less than higher priority tasks active at time (otherwise they will occupy all the cores). ∎
Since Lemma 2 holds for all tasks with higher priority than , an immediate corollary is that the number of security tasks with carry-in at also cannot be larger than . If a security task does not have carry-in, its workload is maximized when the task is released at the beginning of the busy interval. Hence, we can calculate the workload bound for the interval using Eq. (2), e.g., . Likewise, the workload bound for a carry-in security task in an interval of length starting at is given by (see Fig. 4):
where . We can bound the workload of the first carry-in job to because the job must have started executing at the latest at (given that not all cores are busy). Finally, using the same argument as in Section 4.2, the interference of can be bounded as follows:
where is either or . Notice that the WCRT and periods of security task in the carry-in workload function (see Eq. (4)) is actually an unknown parameter. However, we follow an iterative scheme that allows us to calculate the period and WCRT of all higher priority security tasks before we calculate the interference for task (refer to Section 4.5 for details).
4.4. Response Time Analysis
Let ) denote the set of security tasks with a higher priority than . Note that we do not know which (at most) security tasks in have carry-in. In order to derive the WCRT of , let us define as the set of all partitions of into two subsets and (e.g., the non overlapping set of carry-in and non-carry-in tasks) such that:
e.g., there are at most carry-in tasks. For a given carry-in and non-carry-in set (e.g., and ), we can calculate the total interference experienced by as follows:
For a given sets response time will be the minimal solution of the following iteration555Note that the worst-case is when the job arrives at (i.e., ). (guan2009new_wcrt_bound):
We can solve this using an iterative fixed-point search with the initial condition . The search terminates if there exists a solution (i.e., for some iteration ) or when for any iteration since becomes trivially unschedulable for WCRT greater than . Finally we can calculate the WCRT of as follows:
The security task remains schedulable with any period . However as mentioned earlier, the calculation of requires us to know the period and response time of other high priority tasks . Also if we arbitrarily set (since this allows us to execute security tasks more frequently) it may negatively affect the schedulability of other tasks that are at a lower priority than because of a high degree of interference from . Hence, we developed an iterative algorithm that gives us a trade-off between schedulability and monitoring frequency.
Our proposed solution (refer to Algorithm 1 for a formal description) works as follows. We first fix the period of each security task and calculate the response time using the approach presented in Section 4.3 (Line 1). If there exists a task such that we report the taskset as unschedulable (Line 2) since it is not possible to find a period for the security tasks within the designer provided bounds – this unschedulability result will help the designer in modifying the requirements (and perhaps RT tasks’ parameters, if possible) accordingly to integrate security tasks for the target system. If the taskset is schedulable with , we then iteratively optimize the periods from higher to lower priority order (Lines 5-9) and return the period (Line 10). To be specific, for each task we perform a logarithmic search (knuth1997art, Ch. 6) (see Algorithm 2 for the pseudocode) and find the minimum period within the range such that all low priority tasks (denoted as ) remain schedulable, e.g., (Line 7). Note that since we perform these steps from higher to lower priority order, WCRT and period of all higher priority tasks (e.g., ) are already known. We then update the response times of all low priority task considering the interference from the newly calculated period (Line 8) and repeat the search for next security task.
We evaluate HYDRA-C on two fronts: (i) a proof-of-concept implementation on an ARM-based rover platform with security applications – to demonstrate the viability of our scheme in a realistic setup (Section 5.1); and (ii) with synthetically generated workloads for broader design-space exploration (Section 5.2). Our implementation code will be made available in a public, open-sourced repository (mhasan_conex_implementation).
5.1. Experiment with an Embedded Platform and Security Applications
5.1.1. Platform Overview
We implemented our ideas on a rover platform manufactured by Waveshare (waveshare). The rover hardware/peripherals (e.g., wheel, motor, servo, sensor, etc.) are controlled by a Raspberry Pi 3 (RPi3) Model B (rpi3) SBC (single board computer). The RPi3 is equipped with a 1.2 GHz 64-bit quad-core ARM Cortex-A53 CPU on top of Broadcom BCM2837 SoC (system-on-chip). In our experiments we focus on a dual-core setup (e.g., activated only core0 and core1) and disabled the other two cores) – this was done by modifying the boot command file /boot/cmdline.txt and set the flag maxcpus=2. The base hardware unit of the rover is connected with RPi3 using a 40-pin GPIO (general-purpose input/output) header. The rover supports omni-directional movement and can move avoiding obstacles using an infrared sensor (e.g., ST188 (ST188)). We also attached a camera (RPi3 camera module) that can capture static images (3280 2464 pixel resolution). The detailed specifications of the rover hardware (e.g., base chassis, adapter, etc.) are available on the vendor website (waveshare).
5.1.2. Experiment Setup and Implementation
We implemented our security integration scheme in Linux kernel 4.9 and enabled real-time capabilities by applying the PREEMPT_RT patch (rt_patch) (version 4.9.80-rt62-v7+). In our experiments the rover moved around autonomously and periodically captured images (and stored them in the internal storage). We assumed implicit deadlines for RT tasks and considered two RT tasks: (a) a navigation task – that avoids obstacles (by reading measurements from infrared sensor) and navigates the rover and (b) a camera task that captures and stores still images. We do not make any modifications to the vendor provided control codes (e.g., navigation task). In our experiments we used the following parameters : ms and ms, for navigation and camera tasks, respectively (i.e., total RT task utilization was . We calculated the WCET values using ARM cycle counter registers (CCNT) and set periods in a way that the rover can navigate and capture images without overloading the RPi3 CPU. Since CCNT is not accessible by default, we developed a Linux loadable kernel module and activated the registers so that our measurement scripts can access counter values. To integrate security into this rover platform, we included two additional security tasks: (a) an open-source security application, Tripwire (tripwire), 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 an expected profile of modules. The WCET of the security tasks were ms and ms, respectively and the maximum periods of security tasks were assumed to be ms (e.g., total system utilization is at least ) – we picked this maximum period value by trial and error so that the taskset became schedulable for demonstration purposes. We used the Linux taskset utility (linux_taskset) for partitioning tasks to the cores and the tasks were scheduled using Linux native sched_setscheduler() function. For accuracy of our measurements we disabled all CPU frequency scaling features in the kernel and executed RPi with a constant frequency (e.g., 700 MHz – the default value). The system configurations and tools used in our experiments are summarized in Table 2.
|Platform||1.2 GHz 64-bit Broadcom BCM2837|
|Operating System||Debian Linux (Raspbian Stretch Lite)|
|Kernel version||Linux Kernel 4.9|
|Real-time patch||PREEMPT_RT 4.9.80-rt62-v7+|
|Boot parameters||=2, =1, =700, =700|
|WCET measurement||ARM cycle counter registers|
|Task partition||Linux taskset|
We compared the performance of our scheme with prior work, HYDRA (mhasan_date18). In that work, researchers proposed to statically partition the security tasks among the multiple cores – to our knowledge HYDRA is the state-of-the-art mechanism for integrating security in legacy multicore-based RT platforms. The key idea in HYDRA was to allocate security tasks using a greedy best-fit strategy: for each task, allocate it to a core that gives maximum monitoring frequency (i.e., shorter period) without violating schedulability constraints of already allocated tasks.
5.1.3. Experience and Evaluation
We observed the performance of HYDRA-C by analyzing how quickly an intrusion can be detected. We considered the following two realistic attacks666Note: our focus here is on the integration of any given security mechanisms rather the detection of any particular class of intrusions. Hence we assumed that there were no zero-day attacks and the security tasks were able the detect the corresponding attacks correctly (i.e., there were no false-positive/negative errors) – although the generic framework proposed in this paper allows the designers to accommodate any desired security (e.g., intrusion detection/prevention) technique.: (i) an ARM shellcode (arm_shellcode) that allows the attacker to modify the contents of the image data-store – this attack can be detected by Tripwire; (ii) a rootkit (simple_rootkit) that intercepts all the read() system calls – our custom security task can detect the presence of the malicious kernel module that is used to inject the rootkit. For each of our experimental trials we launched attacks at random points during program execution (i.e., from the RT tasks) and used ARM cycle counters to measure the detection time. In Fig. 4(a) we show the average time to detect both the intrusions (in terms of cycle counts, collected from trials) for HYDRA-C and HYDRA schemes. From our experiments we found that, on average, our scheme can detect intrusions faster compared to the HYDRA approach (Fig. 4(a)). Since our scheme allows security tasks to migrate across cores, it provides smaller response time (e.g., shorter period) in general and that leads to faster detection times. We next measured the overhead of our security integration approach in terms of number of context switches (CS). For each of the trials we observed the schedule of the RT and security tasks for seconds and counted the number of CS using the Linux perf tool (linux_perf). In Fig. 4(b) we show the number of CS (y-axis in the figure) for HYDRA-C and HYDRA schemes (for trials). As shown in the figure, our approach increases the number of CS (since we permit migration across cores) compared to the other scheme that statically partitions security tasks. From our experiments we found that, on average, our scheme increases CS by times. However, this increased CS overhead does not impact the deadlines of RT tasks (since the security tasks always execute with a priority lower than the RT tasks) and thus may be acceptable for many RT applications.
5.2. Experiment with Synthetic Tasksets
We also conducted experiments with (randomly generated) synthetic workloads for broader design-space exploration.
|Number of real-time tasks,|
|Number of security tasks,|
|Period distribution (RT and security tasks)||Log-uniform|
|RT task allocation||Best-fit|
|RT task period,||ms|
|Maximum period for security tasks,||ms|
|Minimum utilization of security tasks||At least of RT tasks|
|Base utilization groups|
|Number of taskset in each configuration|
5.2.1. Taskset Generation and Parameters
In our experiments we used parameters similar to those in related work (mhasan_date18; sibin_RT_security_journal; mhasan_rtss16; sun2014improving_wcrt2; davis2015global; mn_gp) (see Table 3). We considered cores and each taskset instance contained RT and security tasks. To generate tasksets with an even distribution of tasks, we grouped the real-time and security tasksets by base-utilization from where . Each utilization group contained tasksets (e.g., total tasksets were tested for each core configuration). We only considered the schedulable tasksets (e.g., the condition in Section 2.1
was satisfied for all RT tasks) – since tasksets that fail to meet this condition are trivially unschedulable. Task periods were generated according to a log-uniform distribution. Each RT task had periods betweenms and the maximum periods for security tasks were selected from ms. We assumed that RT tasks were partitioned using a best-fit (parti_see) strategy and the total utilization of the security tasks was at least of the system utilization. For a given number of tasks and total system utilization, the utilization of individual tasks were generated using Randfixedsum algorithm (randfixedsum).
5.2.2. Impact on Inter-Monitoring Interval
We first observe how frequently we can execute (schedule) security tasks compared to the designer specified bound (Fig. 6). The x-axis of Fig. 6 shows the normalized utilization where is the minimum utilization requirement and given as follows: The y-axis represents the Euclidean distance between the calculated period vector and maximum period vector (normalized to ). A higher distance implies that tasks can run more frequently. As we can see from the figure for higher utilizations, the distance reduces (e.g., periods are closer to the maximum value) – this is mainly due to the interference from higher priority (RT and security) tasks. The results from this figure suggest that we can execute security tasks more frequently for low to medium utilization cases.
5.2.3. Impact on Schedulability and Security Trade-off
While in this work we consider a legacy RT system (i.e., where RT tasks are partitioned to respective cores), for comparison purposes we considered the following two schemes (in addition to the related work, HYDRA, introduced in Section 5.1) that do not consider any period adaptation for security tasks.
GLOBAL-TMax: In this scheme all the RT and security tasks are scheduled using a global fixed-priority multicore scheduling scheme (mutiprocessor_survey). Since our focus here is on schedulability we set (recall that a taskset can be considered schedulable if the following conditions hold: and ). This scheme allows us to observe the performance impacts of binding RT tasks to the cores (due to legacy compatibility).
HYDRA-TMax: This is similar to the HYDRA approach introduced in Section 5.1 (i.e., security tasks were partitioned using best-fit allocation as before) but instead of minimizing periods here we set . This allows us to observe the trade-offs between schedulability and security in a fully-partitioned system.
In Fig. 6(a) we compare the performance of HYDRA-C with the HYDRA, GLOBAL-TMax and HYDRA-TMax strategies in terms of acceptance ratio (y-axis in the figure) defined as the number of schedulable tasksets (e.g., ) over the generated one and the x-axis shows the normalized utilization . As we can see from the figure, HYDRA-C outperforms HYDRA when the utilization increases (i.e., ). This is because our scheme allows security tasks to execute in parallel across cores and also allocate periods considering the schedulability constrains of all low priority tasks – this results in a smaller response time and can find more tasksets that satisfy the designer specified bound. In contrast HYDRA uses a greedy approach that minimizes the periods of higher priority tasks first without considering the global state. Also HYDRA statically binds the security task to the core and hence suffers interference from the higher priority tasks assigned to that core – this leads to lower acceptance ratios. For higher utilizations (i.e., ) HYDRA-C can find tasksets schedulable that can not be easily partitioned by using the HYDRA-TMax scheme. The acceptance ratio of our method and the HYDRA-TMax scheme is equal when . This is because, for lower utilizations some lower priority security tasks experience less interference due to longer periods and specific core assignment (recall we set for all security tasks). While we bind the RT tasks to cores (due to legacy compatibility), it does not affect the schedulability (i.e., the acceptance ratio of HYDRA-C is higher when compared to the GLOBAL-TMax scheme). This is because, RT tasks are already schedulable when partitioned (e.g., by assumption on taskset generation, see Section 5.2.1) and our analysis reduces the interference that RT tasks have on security ones. For higher utilizations, the acceptance ratio drops for all the schemes since it is not possible to satisfy all the constraints due to the high interference from RT and security tasks. We also highlight that while our approach results in better schedulability, HYDRA-C/HYDRA-TMax (i.e., where legacy RT tasks are partitioned to the cores) and GLOBAL-TMax (i.e., where all tasks can migrate) schemes are incomparable in general (e.g., there exists taskset that may be schedulable by task partitioning but not in global scheme where migration is allowed and vice-versa) – we allow security tasks to migrate due to security requirements (e.g., to achieve faster intrusion detection – as we explain in the next experiments, see Fig. 6(b)). In the final set of experiments (Fig. 6(b)) we compare the achievable periods (in terms of Euclidean distance) for our approach and the other schemes. The x-axis in the Fig. 6(b) shows the normalized utilizations and the y-axis represents the average difference between the following period vectors: (a) between HYDRA-C and HYDRA (dashed line); (b) HYDRA-C and other strategies (e.g., GLOBAL-TMax and HYDRA-TMax) that do not consider period minimization (dotted marker) for dual and quad core setup. Higher distance values imply that the periods calculated by HYDRA-C are smaller (i.e., leads to faster detection time) and our approach outperforms the other scheme. For low to medium utilizations (e.g., ) HYDRA-C performs better when compared to HYDRA. In situations with higher utilizations, the lesser availability of slack time results in HYDRA-C and HYDRA performing in a similar manner. Also, for higher utilizations HYDRA is unable to find schedulable tasksets and hence there exist fewer data points. Our experiments also show that compared to GLOBAL-TMax and HYDRA-TMax our approach finds smaller periods in most cases (Fig. 6(b)). This is expected since there is no period adaptation (i.e., we set for those schemes). However it is important to note that HYDRA-C achieves better execution frequency (i.e., smaller periods) without sacrificing schedulability as seen in Fig. 6(a). That is, our semi-partitioned approach achieves better continuous monitoring 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.
In this paper we do not design for any specific security tasks (the IDS system used is meant for demonstration purposes only) and allow designers to integrate their preferred techniques. Depending on the actual implementation of the security tasks some attack may not be detectable. For instance, the system may be vulnerable to zero-day attacks if the security tasks are not designed to detect unforeseen exploits or anomalous behaviors. There exists cases where security tasks may require some amount of system modifications and/or porting efforts – say a timing behavior based security checking (hamad2018prediction; securecore; dragonbeam) may require the insertion of probing mechanisms 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 monitoring events) and works in a proactive manner. However, designers may want to integrate security tasks that react, based on anomalous behavior. For instance, let at time , -th job of task (e.g., ) performs action (e.g., runtime of real-time tasks). Because of intrusions (or perhaps due to other system artifacts) in time ( is the period of ), job finds that is not behaving as expected. Therefore may perform both actions, and (say that checks the list of system calls, to see if any undesired calls are executed). One way to support such a feature is to consider the dependency (i.e., depends on in this case) between security checks (e.g., sub-tasks). We intend to extend our framework considering dependency between security tasks.
7. Related Work
RT Scheduling and Period Optimization
Although not in the context of RT security, the scheduling approaches present in this paper can be considered as a special case of prior work (linux_push_pull) where each task can bind to any arbitrary number of available cores. For a given period, this prior analysis (linux_push_pull) is pessimistic for the model considered by HYDRA-C (i.e., RT tasks are partitioned and security tasks can migrate on any core) in a sense that it over-approximates carry-in interference from the tasks bound to single cores (e.g., RT tasks) and hence results in lower schedulability (e.g., identical to the GLOBAL-TMax scheme in Fig. 6(a)). Researchers also propose various semi-partitioned scheduling strategies for fixed-priority RTS (kato2009semi; lakshmanan2009partitioned). However, this work primarily focuses on improving schedulability (e.g., by allowing highest priority task to migrate) and they are not designed for security requirements in consideration (e.g.,
minimizing periods and executing security tasks with fewer interruption for faster anomaly detection). There exists other work(delay_period) in which the authors statically assign the periods for multiple independent control tasks considering control delay as a cost metric. Davare et al. (davare2007period_can) propose to assign task and message periods as well as satisfy end-to-end latency constraints for distributed automotive systems. While the previous work focus on optimizing period of all the tasks in the system for a single core setup, our goal is to ensure security without violating timing constraints of the RT tasks in a multicore platform.
Security Solutions for RTS
In recent years researchers proposed various mechanisms to provide security guarantees into legacy and non-legacy RTS (both single and multicore platforms) in several directions, viz., integration of security mechanisms (mhasan_rtss16; mhasan_ecrts17; mhasan_date18), authenticating/encrypting communication channels (lesi2017network; lesi2017security; xie2007improving; xie2005dynamic; lin2009static; jiang2013optimization), side-channel defence techniques (sg1; sg2; sibin_RT_security_journal; taskshuffler; volp_TT_randomization) as well as hardware/software-based frameworks (mohan_s3a; securecore; securecore_memory; slack_cornell; securecore_syscal; mhasan_resecure16; mhasan_resecure_iccps). Perhaps the closest line of research is HYDRA (mhasan_date18) where authors proposed to statically partition security tasks to the cores and used an optimization-based solution to obtain the periods. While this approach does not have the overhead of context switches across 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 to slower detection of intrusions (i.e., less effective). The problem of integrating security for single core RTS is addressed in prior research (mhasan_rtss16) where authors used hierarchical scheduling (server_ab_uk) and proposed to execute security tasks with a low priority server. This approach is also extended to a multi-mode framework (mhasan_ecrts17) that allows security tasks to execute in different modes (i.e., passive monitoring with lowest priority as well as exhaustive checking with higher priority). These server-based approaches, however, may require additional porting efforts for legacy systems. There exists recent work (lesi2017network; lesi2017security) to secure cyber-physical systems from man-in-the-middle attacks by enabling authentication mechanisms and timing-aware network resource scheduling. There has also been work (xie2005dynamic; xie2007improving; lin2009static) where authors proposed to add protective security mechanisms into RTS and considered periodic task scheduling where each task requires a security service whose overhead varies according to the required level of service. The problem of designing secure multi-mode RTS have also been addressed in prior work (jiang2013optimization) under dynamic-priority scheduling. In contrast, we consider a multicore fixed-priority scheduling mechanism where security tasks are executed periodically, across cores, while meeting real-time requirements. The above mentioned work are designed for single core platforms and it is not straightforward to retrofit those approaches for multicore legacy systems. In another direction, the issues related to information leakage through storage timing channels using shared architectural resources (e.g., caches) is introduced in prior work (sg1; sg2; sibin_RT_security_journal). The key idea is to use a modified fixed-priority scheduling algorithm with a state cleanup mechanism to mitigate information leakage through shared resources. However, this leakage prevention comes at a cost of reduced schedulability. Researchers also proposed to limit inferability of deterministic RT schedulers by randomizing the task execution patterns. Yoon et al. (taskshuffler) proposed a schedule obfuscation method for fixed-priority RM systems. A combined online/offline randomization scheme (volp_TT_randomization) is also proposed to reduce determinism for time-triggered (TT) systems where tasks are executed based on a pre-computed, offline, slot-based schedule. We highlight that all the aforementioned work either requires modification to the scheduler or RT task parameters, and is designed for single core systems only. Unlike our approach that works at the scheduler-level, researchers also proposed hardware/software-based architectural solutions (mohan_s3a; onchip_fardin; securecore; securecore_memory; slack_cornell; securecore_syscal; mhasan_resecure16; mhasan_resecure_iccps) to improve the security posture of future RTS. Those solutions require system-level modifications and are not suitable for legacy systems. To our knowledge this is the first work that aims to achieve continuous monitoring for multicore-based legacy RT platforms.
Threats to safety-critical RTS are growing and there is a need for developing layered defense mechanisms to secure such critical systems. We present algorithms to integrate continuous security monitoring for legacy multicore-based RTS. By using our framework, systems engineers can improve the security posture of RTS. This additional security guarantee also enhances safety – which is the main goal for such systems.