The EPA-RIMM prototype demonstrates a functional UEFI-based EPA-RIMM measurement on two commodity open-hardware platforms: Minnowboard Turbot and UP2 boards. EPA-RIMM has also been ported by John Fastabend to use coreboot firmware [24]. With new open-hardware platforms that support coreboot [60, 96], this presents additional deployment options. Our open- source release of the EPA-RIMM software stack represents the first publicly- available SMM-RIMM prototype. Our prototype demonstrates detection of attacks involving changes to CPU control registers, kernel and hypervisor code injection, as well as the possibility of detecting some transient malware.
To evaluate EPA-RIMM’s ability to provide the SMM measurement agent with enough context to detect rootkit and ransomware techniques, we de- veloped simulated attacks that performed the same resource compromises as done in recent examples of these types of malware. EPA-RIMM detected these compromises by leveraging its provisioning phase and measurement API.
Chapter 8. EPA-RIMM Prototype 152
The BEM provides a wide variety of test options that enabled a wide vari- ety of test scenarios, including measurements over the cost of cryptography operations, SMI processing costs, and varying Bin and Task sizes. The In- spector supports the flexible measurement description API and allows rootkit detection without building state into SMRAM. The HCM provides an example of the necessary communications between the Inspector and the BEM, serving as a pass-through for encrypted data flowing between these two endpoints.
The resulting application impacts of EPA-RIMM demonstrate that the resulting performance is dependent on the size and frequency of the EPA- RIMM measurements, representing a useful tuning knob. If EPA-RIMM administrators want to minimize the impact on a latency-sensitive system, system impacts can be greatly reduced by adjusting these knobs. However, if the infrastructure is under attack, these knobs present the means to perform deeper inspections to identify issues sooner.
9
Task Scheduling in EPA-RIMM
Each EPA-RIMM measurement incurs an SMI entry and exit cost. This mo- tivates a need to make effective use of the time spent in SMM as these fixed costs are incurred for any measurement. Additionally, with a large measure- ment queue, maintaining a high measurement throughput is important to ensure that the Checks that the Diagnosis Manager added are processed in a timely manner.
EPA-RIMM’s Backend Manager plays a key role in effectively allocating sets of work to be performed in each SMM session. As new Checks can arrive at any point in time, the precise set of Tasks to form Bins over is not known at the outset of the simulator operation. Thus, the Backend Manager must perform an online Bin formation without knowledge of what Tasks may may arrive in the future. If available Bin capacity is not effectively used, the overheads of entering and exiting SMM will be incurred but fewer measure- ments will be performed, hurting efficiency. This results in increased system performance degradation and slower progress through the measurement queue.
Bin size and Bin frequency also play a key role in the effectiveness of pro- cessing a large set of measurements. Increasing both of these results in faster processing of the measurement queue, however, this results in additional system overhead. The question of how to prevent starvation of older Tasks on the queue when new Tasks arrive also merits investigation. To facilitate an understanding of these questions, we developed a simulator, RIMM-SIM. This simulator allows varying key adjustable parameters to explore schedul- ing efficiency, speed of measurement processing, and prevention of Task starvation.
Chapter 9. Task Scheduling in EPA-RIMM 154
As different EPA-RIMM deployments could measure different resources, it is possible that the incoming Checks arriving at the Backend Manager may fall into various sizes. For example, memory hashes of small data structures might take minimal time whereas measurements over the entire Linux kernel could be decomposed into larger Task sizes where one Task consumes all of the available Bin capacity. For this reason, we evaluate two scenarios for Checks arriving at the Backend Manager: Uniform distribution and a normal distribution. The uniform distribution option allows examining the impacts of a wide variety of incoming Tasks where their costs do not cluster around a median value. We envision that there may also be scenarios where measurement sizes may cluster around a mean value and thus we also evaluate a normal distribution.
In Section 9.1, we provide background information for the Knapsack Prob- lem, First Come First Serve, and a Priority queue with optional backfilling and aging features. In Section 9.2, we provide the results of our experiments that investigate the performance of the First Come First Serve and Priority Queue with backfilling and aging options. We discuss our results in Section 9.3.
9.1 Scheduling Approaches
We begin with the the Knapsack Problem, the cover the First Come First Serve algorithm, the Priority queue, and priority queues with backfilling and aging.
9.1.1 Knapsack Problem
The classic "0/1" Knapsack Problem [92] consists of a knapsack that can hold a capacity of W (weight), a set of items from 1 to N with weights wi to wN
and values vi to vN. The goal is to choose an optimal subset of items with
a weight no greater than W and the highest-possible value. The classic 0/1 Knapsack Problem is NP-Complete [17]. Applying this to EPA-RIMM Bin
formation, the maximum weight, W, can be set to maximum Bin size. The weights are the measurement costs and the values are the Task priorities.
In contrast, the fractional Knapsack Problem allows dividing items into fractions which could allow better utilization of the available capacity. How- ever, this variant is not applicable to EPA-RIMM as a finite set of hash values is gathered during EPA-RIMM’s provisioning phase and measuring reduced sizes in an attempt to better fill a Bin would result in different hash values that cannot be evaluated.
9.1.2 First Come First Serve
The First Come First Serve ("FCFS") algorithm is a basic algorithm that selects processes based on their order of arrival. Applied to to EPA-RIMM’s Backend Manager, the Backend Manager would add Tasks from newly arrived Checks to the end of the queue and fill the Bins with Tasks from the front of the queue. This approach does not select tasks deeper in the queue to fill a Bin, even if there would be space for them.
For an example, Figure 9.1 begins in Step 1 with five Tasks on the queue, each with a cost of 33µs. In Step 2, Bin 0 is formed with four 33µs Tasks that together consist of 132µs. As the maximum Bin cost is 150µs, this does not allow the remaining 33µs Task to be included in this Bin. In Step 3, a new set of Tasks (cost is 91µs for each Task) arrives on the queue and is placed at the end. In Step 4, Bin 1 is formed with a 33µs and a 91µs Task. Step 5 shows the resulting priority queue after this Bin formation.
The benefits of this approach are that the method is simple to implement and is not prone to starvation due to processing tasks in order of arrival. A key drawback of the approach is that it can result in less optimally-filled Bins due to an inability to consider Tasks after the head of the queue for inclusion in the Bin.
Chapter 9. Task Scheduling in EPA-RIMM 156