{'fraction_non_alphanumeric': 0.02940219160247369, 'fraction_numerical': 0.010713898231528697, 'mean_word_length': 4.830012650221379, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 1, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 2, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
Memory-Aware Denial-of-Service Attacks on Shared Cache in Multicore Real-Time Systems

In this paper, we identify that memory performance plays a crucial role in the feasibility and effectiveness for performing denial-of-service attacks on shared cache. Based on this insight, we introduce new cache DoS attacks, which can be mounted from the user-space and can cause extreme WCET impacts to cross-core victims---even if the shared cache is partitioned---by taking advantage of the platform's memory address mapping information and HugePage support. We deploy these enhanced attacks on two popular embedded out-of-order multicore platforms using both synthetic and real-world benchmarks. The proposed DoS attacks achieve up to 75X WCET increases on the tested platforms.


INTRODUCTION
Multicore computing platforms are increasingly used in safety-critical cyber-physical systems such as self-driving cars and drones. However, in a multicore platform, a task's execution time can vary significantly due to contention in shared micro-architectural resources when other tasks run concurrently on the platform [12]. Such timing variation in multicore can be exploited by attackers. Consider, for example, a scenario where some cores of a multicore platform are reserved for critical real-time tasks while some other cores are reserved for user downloaded third party programs. Even if the platform's runtime (OS or hypervisor) partitions cores and memory to isolate the potentially dangerous programs from the critical tasks, as long as they share the same multicore computing platform, an attacker controlled downloaded program may still be able to delay the critical tasks, simply by executing code that exhausts shared micro-architectural resources, effectively mounting denial-of-service (DoS) attacks.
Modern multicore processors provide a high-degree of parallelism in accessing memory throughout the memory hierarchy. At the cache-level, non-blocking caches [21] are used, which can be accessed even when there are multiple outstanding cache misses. However, a non-blocking cache can become inaccessible whenever its internal hardware buffers are exhausted, at which point the cache cannot accept any further requests. The cache remains blocked until the internal buffers become available again [1], [32]. For a shared last level cache (LLC), cache blocking is especially problematic because it affects all cores that share the cache, as all requests to the cache would be blocked, regardless of their origins. As a result, the cores need to wait for the cache to unblock, which can take a long time as the cache may need to access slower main memory, which in turn can take hundreds of CPU cycles. Therefore, if an attacker can intentionally induce cache blocking on the shared LLC, they can cause massive timing impacts to the rest of the cores even if they cannot directly access them.
Prior work demonstrated the feasibility and severity of micro-architectural DoS attacks [6], [7], [35] on shared nonblocking caches, which identified two internal cache hardware structures: (1) miss-status-holding-registers (MSHRs), which track individual requests generated from cache misses, and (2) WriteBack Buffers, which temporarily hold and delay cache write-backs, as potential DoS attack vectors. In these works, an attacker simply accesses a large array, which quickly generates a large number of concurrent cache-misses and exhaust those cache internal structuresinducing cache blocking. They showed that conventional cache partitioning techniques are ineffective to defend against such DoS attacks that target internal cache hardware structures, which may still be shared even if the cache space is partitioned.
In this paper, we first experimentally show that the effectiveness of cache DoS attacks is critically dependent on memory performance. This is because the basis for cache DoS attacks-inducing cache blocking-is reliant on how quickly the cache-misses are processed by the lower-level memory hierarchy. If the memory requests can be processed at a relatively faster rate, then cache DoS attacks will be less effective as the cache will not be blocked for as long a time.
On the other hand, if the memory requests are processed more slowly, the cache DoS attacks would be more effective as the likelihood of cache blocking would increase.
Based on this insight, we propose memory-aware cache DoS attacks that can induce more effective cache blocking by taking advantage of information of the underlying memory hardware. Like prior cache DoS attacks, our new attacks also generate continuous cache misses to exhaust cache internal shared hardware resources. The difference is that we carefully control those cache misses to target the same DRAM bank to induce bank conflicts. Note that accesses to different DRAM banks can occur in parallel, and are thus faster. However, accesses to the same bank are serialized, and thus slower [42]. Since each memory access request takes longer to finish, the cache would take longer to become unblocked. We further extend these attacks to exploit HugePage support in Linux to directly control physical address bits and to avoid TLB misses, while mounting the attacks from the userspace.
We deploy the proposed memory-aware DoS attacks on two contemporary embedded multicore platforms using both synthetic and real-world representative benchmarks. We find that the proposed DoS attacks are significantly and consistently more effective at impacting victim task's WCET when compared to existing state-of-the-art DoS attacks. For instance, on one embedded multicore platform we tested, our proposed attacks result in ∼75X slowdown to a crosscore victim task, while the state-of-the-art cache DoS attacks cause ∼21X slowdown.
This paper makes the following contributions: • We show that main memory (DRAM) performance plays a crucial role in the feasibility and effectiveness of denial-of-service attacks on shared cache.

•
We propose new cache DoS attacks that leverage platform's memory address mapping information and HugePage support to induce prolonged shared cache blocking by intentionally generating lots of memory bank conflicts in accessing memory.

•
We experimentally demonstrate the effectiveness of the proposed DoS attacks on two embedded multicore processors using both synthetic and real-word applications. The results show that our attacks are significantly more effective than the state-of-the-art.
The remainder of this paper is organized as follows: Section 2 provides necessary background on cache DoS attacks, memory address mappings and HugePages. Section 3 defines the threat model. Section 4 provides motivation for targeting memory performance. Section 5 discusses the cache DoS attacks and how they function. Section 6 details how the enhanced DoS attacks work and displays their efficacy on embedded multicore platforms. Section 7 reviews how our enhanced attacks can be mitigated, or potentially prevented. We discuss related work in Section 8 and conclude in Section 9.

BACKGROUND
In this section, we provide necessary background.

Non-Blocking Cache
In order to improve cache-level parallelism, modern processors employ non-blocking caches. Figure 1 shows the internal organization of a non-blocking L2 cache, and its two internal hardware structures, Miss-Status-Holding-Registers (MSHRs) and the WriteBack (WB) buffer.
On a non-blocking cache, when a cache-miss occurs, an MSHR entry is allocated to record the miss related information. The MSHR entry is then cleared only when the desired cache-line is returned from the lower levels of the memory hierarchy (e.g., LLC, DRAM). Note that while the outstanding cache miss is being serviced, the cache can still service memory requests from the CPU cores or higher-level Core I D On the other hand, the WriteBack buffer holds dirty cache-lines that are evicted from the cache and need to be written back to the next level in memory. Because reads from memory, such as the cache refills generated from cacheline evictions, are generally more important for application performance, delaying writebacks to memory while reads are being processed can improve system performance by reducing bus contention. The writebacks are then sent to memory when there are no reads being serviced or when the buffer is full. In this way, a non-blocking cache can support concurrent access to the cache efficiently most of the time.

MSHR WB Buffer
Note, however, that when either the MSHRs or WriteBack buffer become full, the entire cache is blocked and rejects all subsequent requests until the cache is unblocked when both structures have free entries available. Unfortunately, unblocking can take a relatively long time as it depends on response times from the lower memory levels. In the worst case, it can take upwards of hundreds of CPU cycles when accesses to the slower main memory are required, which are then affected by how congested the DRAM controller is. Cache blocking is especially problematic in shared caches as it affects all cores that share that cache. Even if a task's memory accesses are all cache hits, the task can still suffer massive slowdowns if the cache is blocked for a significant portion of the time.

Cache DoS Attacks
Recent works have demonstrated that the internal hardware structures of a non-blocking cache can be exploited to mount denial-of-service (DoS) attacks [6], [35]. Cache DoS attacks are software attacks that target cache internal hardware structures of a shared non-blocking cache. Generally, they are designed to generate as many cache misses and/or write-backs as fast as possible to overflow the cache internal hardware structures to induce cache blocking [6], [35]. When cache blocking occurs on a shared cache in a multicore processor, it affects all cores and can be devastating. For example, it has been shown that on a popular embedded multicore platform, the Raspberry Pi 3, a cache DoS attack could cause over 300X slowdown to a victim task [6], even when the victim task is running on a different core with its own dedicated cache partition and almost all of its memory accesses are cache hits.

Memory (DRAM) Address Mapping
A DRAM module is organized into ranks and each rank is further divided into multiple banks. A bank contains storage cells, which are organized in rows and columns in a 2D array-like structure. To access data in the storage cells, the corresponding row must be activated, which copies the data of the row into an intermediary buffer, called a row buffer, which acts as a cache. While in the row buffer, the data can be read from/written to efficiently. To access a different row, however, the current row needs to be closed (precharged). Since both activation and precharge take considerable time, accesses to different rows in the same bank can decrease memory performance.
To access specific locations in the memory, the system's DRAM controller employs a memory address mapping scheme that translates a given physical address to the DRAM specific addresses (module, rank, bank and row, column). Because DRAM banks can be accessed in parallel, the address mapping of DRAM banks is particularly important for performance-if multiple concurrent memory requests are mapped over different banks, they can be processed efficiently in parallel; if, however, they are mapped to the same bank, resulting bank conflicts will slowdown the memory performance.  Figure 2 shows the address mapping information of the Odroid XU4 platform. In this platform, five physical address bits-7, 13, 14, 15, and 16-are used by the DRAM controller to map 32 different DRAM banks of the system's main memory. Such DRAM bank mapping information can be obtained experimentally [29], [41] or through platform documentations. If one can control these physical address bits in allocating memory blocks, the person can control the DRAM banks on which the allocated memory blocks will be located.

HugePages
In a virtual memory-based system, memory is typically allocated in 4KB page granularity. However, for large applications, the 4KB page size can be a performance bottleneck due to increased address translation overhead (TLB miss, page fault handling, etc.) To address the shortcomings of 4KB small pages, HugePage support was introduced in Linux kernel (since v2.6), which gave the option to use larger page granularities when allocating memory (e.g. 2MB pages). This reduces the number of pages used by applications and the CPU's TLB pressure, as each TLB entry can cover a larger address range (2MB vs. 4KB). As the 64-bit ARM architecture has become mainstream, increasingly many ARM based embedded platforms and operating systems already support HugePage. Note that support for HugePage can be beneficial for embedded real-time systems as it can significantly improve time predictability of the real-time applications.   Note that this means that allocating a single 2MB hugepage allows us to control a larger portion of the physical address space without requiring any system privileges. In the following, we will exploit this ability to control physical address in creating effective cache DoS attacks. We assume both the victim and attacker are co-located on the same multicore processor, but they run on their own dedicated cores, as shown in Figure 4. We assume that each core of the multicore processor has private caches, but all cores share a single shared last-level cache (LLC). We assume that the system's runtime (OS and hypervisor) provides core, memory, and LLC space partitioning capabilities. For partitioning the LLC, we assume page coloring [41] is implemented in the runtime. We assume that the system supports HugePages. We assume that the attacker can obtain the system's DRAM bank mapping information, via experimental methods [24], [28], [29], [41] or from a manual. Lastly, we assume that the attacker has no privileges on the system and can only run non-privileged code on its assigned attacker cores.

THREAT MODEL
In this setting, the attacker's primary goal is to delay execution time of the victim task by mounting denial-ofservice attacks on the shared cache.

IMPACT OF MEMORY PERFORMANCE TO CACHE DOS ATTACKS
In this section, we provide an experimental evidence on the impact of memory performance to the effectiveness of cache DoS attacks.
As discussed in Section 2, cache DoS attacks [6], [35] attempt to exhaust internal hardware buffers of a shared non-blocking cache to induce cache blocking. The cache becomes unblocked when the cache internal buffers become available again, which would require accesses to main memory. Therefore, we hypothesize that if the access to memory takes longer, the longer the cache would be blocked. In other words, our hypothesis is that poor memory performance would increase the effectiveness of cache DoS attacks.
To test the hypothesis, we perform the same cache DoS attack experiments as in [6]. That is, we measure the slowdown of a synthetic victim task on Core 0 while coscheduling cache DoS attackers on Cores 1-3 on a Raspberry Pi 3. Likewise, we structure the tasks such that the victim fits inside the LLC while all attackers fit inside of memory (i.e. their working set size is greater than the size of the LLC) and partition the LLC so that the attackers can't directly affect the victim's performance through cache evictions.
Unlike previous experiments, however, we make use of the Pi 3's ability manually control the memory frequency of its LPDDR2 memory module by modifying the sdram freq parameter in the config.txt file in the boot partition. By default, the Pi 3 operates at 900 MHz, but it can be changed to run anywhere between 100 to 1000 MHz. In our testing, we configure the memory to run from 1000 MHz down to 100 MHz, in increments of 100 MHz. Figure 5 shows the results. As we expected, the operating frequency of the shared memory, and by proxy the memory's performance, has significant impact to the effectiveness of cache DoS attacks. As we decrease the frequency, the slowdown experienced by the victim task significantly increases. In particular, when we lower the frequency to only 100 MHz, we observe more than 900X WCET increase of the victim task. Note that the victim was not supposed to be 1. The icons are by icons8: https://icons8.com/ affected by slow DRAM performance as its working-set fit in its own cache partition. The reason for this "unexpected" massive WCET increase of the victim is that the slow DRAM access speed results in longer shared cache blocking when the attackers generate lots of concurrent cache misses even though the attackers are on different cores and accessing their own dedicated cache partitions. Based on this finding, we hypothesize that DoS attacks can be more effective if they target main memory, in addition to the shared LLC, with the goal of decreasing its performance.
The simplest and most straight-forward way to accomplish this would be to directly modify and lower the performance of the main memory. However, in a real-world setting, attackers would neither have the required privileges nor physical access to the target machine in order for such approaches to be viable.
Therefore, in this work, we focus on software approaches to create more effective DoS attacks by generating memory access patterns that are slower to process at the hardware level, and thereby improve the effectiveness of cache DoS attacks. To achieve this, we make use of a system's memory address mapping information and HugePage support as we detail in the following section.

MEMORY-AWARE CACHE DOS ATTACK
In this section, we discuss memory access characteristics of prior cache DoS attacks and their limitations, followed by the proposed memory-aware cache DoS attacks. Figure 6 shows the code snippets of the prior cache DoS attacks [6], [35], which perform a series of sequential memory accesses over a large array.

Sequential Attack
The BwRead attack iteratively reads entries of a large onedimensional array at a cache-line granularity (LINE SIZE, typically 64 bytes). When mem size is larger than the size of the LLC, it generates lots of cache-misses, which would access the main memory. On a modern processor, multiple cache-misses can occur concurrently-with the help of outof-order execution and/or hardware prefetchers-which may stress the MSHRs of the LLC [ Fig. 6: Sequential memory access attacks. LINE_SIZE = a cache-line size.
The BwWrite attack operates in a similar manner, but instead writes a value to each array entry. This will then generate continuous store operations that can also be configured to intentionally miss the LLC. Again, multiple write misses can occur concurrently, which can stress both the MSHRs and the Writeback Buffer of the cache. This is because each missed write can generate up to two memory requests: a read for a cache linefill and a write for a cache writeback [6].
While these attacks are effective at generating a large number of concurrent cache misses-nnecessary to overflow the cache internal buffers-the sequential memory access nature of these attacks means these cache misses can be processed efficiently at the memory level. Concretely, success memory blocks (64B cache-lines) are likely to be allocated on the same DRAM row (e.g., 8KB), which are then efficiently processed at the DRAM as costly row switching is not required. Efficient processing at memory is undesirable from the perspective of a cache DoS attack because the goal of the attack is to induce longer cache blocking and fast memory performance would reduce the duration of cache blocking.

Parallel Linked-List Attack
To address the shortcomings of the sequential memory access-based cache DoS attacks, we first introduce parallel linked-list attacks, which generate concurrent random memory accesses. Figure 7 shows the code snippets for the parallel linkedlist attacks: LatencyRead for read and LatencyWrite for write. In both cases, the attacks traverse a set number of linked lists, which can be accessed concurrently on a modern outof-order core because there is no data dependency between the entries of different lists. Each linked list is then randomly shuffled over a large memory space to prevent data prefetching. As such, the number of linked lists determines the degree of memory-level parallelism (MLP) of the attacks. Note that the parallel-linked list attacks are based on the MLP measurement code in [11].
Like the sequential access attacks, the parallel-linked list attacks are designed to generate concurrent cache-misses, which would stress cache internal hardware buffers and induce cache blocking. However, the parallel-linked list attacks are potentially less efficient in memory as successive memory requests due to the cache-misses are likely to be mapped to different DRAM rows, which would require costly row switching. Note, however, entries of these linkedlists may still be mapped to different DRAM banks, and thus can be processed in parallel in DRAM. In such a situation, despite the overhead of frequent row-switching, the concur-  rent cache-misses may still be processed efficiently, which is undesirable from the perspective of cache DoS attacks.

DRAM Bank-Aware Parallel Linked-List Attack
To overcome the limitations-efficient memory processing-of the prior cache DoS attacks, we propose a memory-aware cache DoS attack, which is based on the parallel-linked list attack code (Section 5.2) but differs in that the entries of the linked-lists are constructed in such a way that they are all allocated in the same DRAM bank. The rational is that when multiple accesses target the same bank, they will take longer to be serviced at the DRAM because of increased DRAM bank conflicts and frequent row switching.
To create such linked lists, the attack code allocates a set of 2MB huge pages. It then creates a user-defined number of linked lists and populates them with addresses specifically chosen to be mapped to the same DRAM bank, utilizing the system's DRAM bank address mapping information. (e.g., the Odroid XU4 we test uses physical address bits 13-16 as DRAM bank addresses). Figure 8 shows the address coloring code snippet that is used by the attacks for finding addresses that correspond to the same memory bank. Specifically, it checks the value of each bit in a given address that corresponds to the set of bits specified in the mask bitmask, which is the platform's physical address bits that are mapped to DRAM banks. If the returned value is zero, which means that the given physical address would be mapped to the DRAM bank zero, we add the address to the linked list as a new entry, otherwise we discard the address and continue. In these attacks, since 2MB pages are used for memory allocation, the attack code can effectively control both the physical and  virtual addresses of the list entries. This is because the first 21 bits of the phsyical addresses are identical to the 21bit offset in the corresponding virtual address. In our test platforms, this bit range was sufficient to control DRAM bank mappings. As a result, all of the linked lists generated, and their entries, will be allocated to the same memory bank which will, in turn, generate bank contention.
One notable shortcoming of the proposed memoryaware attacks is that they do not support in-order processing cores, such as the Cortex A53 used by the Raspberry Pi 3. This is because in-order cores cannot concurrently traverse multiple linked lists. As such, they would not be able to generate the necessary amount of concurrent memory requests for cache blocking to occur. As such, we instead target outof-order core architectures that are inherently capable of generating multiple memory requests so that our attacks can still successfully and effectively generate cache blocking.

EVALUATION
In this section, we evaluate the effectiveness of the proposed memory-aware cache DoS attacks on two embedded multicore-based platforms using both synthetic and realword applications.  We deploy our DoS attacks on two embedded multicore platforms: an Odroid XU4 and a Raspberry Pi 4 Model B. The Odroid XU4 employs a big.LITTLE processor configuration comprised of a smaller 4xCortex-A7 [4] in-order core cluster and a larger 4xCortex-A15 [3] out-of-order core cluster. Note that we do not use the Cortex-A7 cluster on the Odroid XU4 as we are primarily focused on out-oforder architecture designs. The second platform we test, the Raspberry Pi 4, only equips a single cluster of 4x Cortex-A72 out-of-order cores. The Cortex-A15 and Cortex-A72 each have a local MLP of 6, with the A15 having a global MLP of 11 [3], [35] and the A72 having global MLP of 19 [5]. Note that we verified the global MLP of the A72 cluster by employing the same MLP micro-benchmark described in Appendix A of [35]. For both multicore systems, we use platform specific DRAM bank bitmasks in the creation of the enhanced attacks linked lists. We reverse engineer the address mapping schemes for both platforms by using the same technique as in [29], [41]. Table 1 shows the characteristics of the tested platforms. The XU4 runs Ubuntu 18.04 and Linux kernel 4.14, while the Pi 4 runs Raspbian Buster and Linux kernel 4.19. Note that both platforms run the latest version of Linux officially supported on them, respectively.  The experimental setup is as follows: we run each victim task alone on a single core, Core 0, to measure its solo response time. We then run the victim task alongside up to three instances of each attacker, scheduled on Cores 1-3, and measure the response times to determine the slowdown each attack caused on the victim relative to the solo case.   For the victim tasks, we use two of the cache DoS attackers-namely BwRead (Section 5.1) and LatencyRead (Section 5.2)-as victim tasks. We selected them as victim tasks as they differ in their access patterns: BwRead performs sequential accesses while LatencyRead performs random accesses. Note that we configure both victims to fit inside the LLC of each tested platform.

Synthetic Workloads
For the attackers, we employ all three cache DoS attack types discussed in Section 5, with each one capable of being read intensive or write intensive, for a total of six attacking tasks. For all attacking processes, we configure their working set sizes to fit inside of DRAM such that they can effectively generate shared cache misses. Figure 9 shows the impacts of cache DoS attacks to the BwRead victim. On Odroid-XU4's Cortex-A15 cluster, both BankRead and BankWrite attackers, which are DRAM Bankaware, caused the most slowdowns to the victim task's performance. The worst case slowdown of the BwRead victim was ∼30X when paired with three BankRead attackers, and ∼56X with three BankWrite attackers. On the Raspberry Pi 4, however, BwRead victim suffers little to no interference from any of the DoS attackers. We believe this difference is due to a combination of the following two factors. First, the Pi 4 equips a more powerful LPDDR4 memory module when compared to the XU4's DDR3 module. As a result, this allows for faster memory accesses on the Pi 4 which ultimately reduces the amount of time the LLC spends blocked, as we explained in Section 4. Second, the Pi 4's Cortex-A72 employs stride-based L1D hardware prefetchers that are triggered after accesses to consecutive cache lines [5]. As such, the sequential access pattern of the BwRead victim would make the L1 prefetcher very effective on the Pi 4. On the other hand, the Cortex-A15 of Odroid-XU4 does not equip L1D prefetcher according to [3]. Hence, XU4's victim is more vulnerable to the LLC blocking than that of Pi 4. Figure 10 shows the impacts of cache DoS attacks to the LatencyRead victim. On Odroid-XU4, BankRead and BankWrite attackers achieves up to ∼40X and ∼75X slowdowns, respectively, to the LatencyRead victim task's performance. Interestingly, unlike the BwRead victim in Figure 9, LatencyRead victim is also significantly affected by BwRead and BwWrite attackers as it suffers up to ∼33.5X slowdown. This is likely because the random access memory pattern of the LatencyRead victim reduces the effectiveness of Cortex-A72 cores' L1D prefetcher.

Impact of Cache Partitioning
In this section, we evaluate the effectiveness of a standard cache isolation mechanism in protecting victim performance from the BankRead and BankWrite attacks. Specifically, we employ a kernel level memory allocator called PALLOC [41] which uses a page coloring technique to control the cache space a process can use for allocating data. Using PALLOC, we partition the L2 cache on the XU4 such that each core is given its own private quarter of the cache space. We then run the same LatencyRead vs. BankRead/BankWrite attacks on the XU4's A15 cluster as that is where we saw the most interference from our enhanced DoS attacks. Figure 11a shows the results. We find that partitioning the cache is ineffective in protecting the performance of the LatencyRead victim as the slowdown observed is practically the same regardless of whether the LLC is partitioned. This is consistent with previous findings [6], [35] as partitioning the cache space does not partition the internal hardware structures, namely the MSHRs and the Writeback Buffer. As such, the DoS attacks can still induce massive shared cache blocking despite cache (space) partitioning.

Impact to Real-World Applications
We also test the effectiveness of our enhanced DoS attacks on real-world applications to test their feasibility.

End-to-End Deep Learning Based Autonomous Vehicle Control
We begin our testing by running DoS attacks against a DNN used by NVIDIA's DAVE-2 system [8] and the DeepPicar autonomous car platform [7]. We employ the same basic experimental setup where a single victim instance is run alone on Core 0 and alongside 1-3 cache DoS attackers on Cores 1-3. For the DNN, we use 1000 video frames as input and calculate the average frame inferencing time. Figure 12 shows the results. Note that when the DNN control task runs on either the XU4's A15 cluster or the Pi 4, the DNN experienced noticeably more slowdown when run alongside BankRead and BankWrite attackers. This is especially true for the BankWrite attackers as they were able to cause ∼5X slowdown on both platforms. Compared to the synthetic victim tests, though, the magnitude of slowdown experienced by the DNN is much less. This is because the DNN task accessed the shared LLC less frequently than the synthetic ones and thus is less impacted by the cache DoS attacks.

Real-World Benchmark Suites
We also deploy the BankWrite DoS attacks against realworld benchmarks from the SPEC2017 [2] and SD-VBS [37] benchmark suites. In total, we use 32 benchmarks as victim tasks, 23 from the SPECrate 2017 Integer suite and all 9 from the SD-VBS suite. For all benchmarks, we employ the same experimental methodology used in Section 6.2. That is, we measure the victim's execution time first alone in isolation and then together with three instances of each of the three different DoS attackers. For the attackers, we choose to only employ only the write versions (BwWrite, LatencyWrite, BankWrite) as they have been shown to generate more contention than their respective read versions. Figure 13a shows the results for the XU4 while Figure 13b shows the results for the Pi 4. Like the DNN, the SPEC2017 and SD-VBS benchmarks suffer the most from the memory-aware cache DoS attack. On the XU4, our best memory-aware attack, BankWrite, achieves a geometric mean of 7.5X slowdown (up to 23 Fig. 12: Impacts of cache DoS attacks to the DeepPicar DNN control task on two multicore platforms. The DNN victim runs on Core 0 while the attackers (X-axis) run on Core 1-3.
In summary, we find that proposed memory-aware attacks are substantially more effective than prior cache DoS attacks in increasing the execution times of real-world applications.

DISCUSSION
In this section, we discuss different system design choices and mechanisms that can be used to effectively prevent the cache DoS attacks we introduce in this paper. In particular, we focus on the two main aspects of our attacks that are necessary for successful DoS attacks and a system design choice that can effectively eliminate MSHR contention.
The key underlying assumption made by our attacks is that the memory address mapping scheme used by a system is already known or can be determined by the attacker. As such, our memory-aware DoS attacks can be prevented by making it difficult to determine such mapping information. For example, employing a XOR addressing scheme [43], and its variations used in recent Intel processors, can defeat our current memory-aware cache DoS attacks.
Another assumption for our attacks is that HugePages are enabled and can be allocated by the attacker. Without HugePage support, only a 4KB address space can be controlled by the non-privileged attacker, which is insufficient  to be able to control DRAM bank allocation on most platforms. Therefore, disabling HugePages or making it accessible to only privileged users can also defeat our memoryaware DoS attacks, though it could also lead to increased timing variability due to increased TLB pressure and page fault handling overhead. The partitioning of cache internal structures (MSHRs, WBBuffer) as proposed in [9], [35] can fundamentally prevent our DoS attacks, although it requires hardware modifications and is not available on COTS processors. Lastly, memory bandwidth throttling can help protect against our cache DoS attacks, as was shown by the OS-based solution presented in [6].

RELATED WORK
Most prior work in the real-time community to improve isolation has been focused on the isolation of shared cache space. Various cache partitioning mechanisms and policies are studied [10], [15]- [18], [22], [25], [34], [38], [39]. However, as shown in prior works [6], [35] and in our experiments in Section 6.3, such partitioning techniques are ineffective at mitigating DoS attacks aimed at the cache's internal hardware structures since they remained shared between all cores, as was shown to be the case in [6], [35].
Denial-of-service (DoS) attacks have been studied for several different types of shared resources in multicore systems. Moscibroda et al. demonstrated DoS attacks on memory (DRAM) controllers. In particular, they found that the widely used FR-FCFS [30] scheduling algorithm, which prioritizes row hits, is susceptible to DoS attacks. To address this, they proposed the use of "fair" scheduling algorithms, which has since been adopted in many memory controllers [19], [26], [27], [33]. Keramidas et al. studied DoS attacks on cache space and proposed a cache replacement policy that allocates less space to such attackers (or cache hungry threads) [14]. Woo et al. investigated DoS attacks on cache bus (between L1 and L2) bandwidth, main memory bus (front-side bus) bandwidth, and shared cache space, on a simulated multicore platform [40]. In contrast, recent prior work focused on internal hardware buffers of shared non-blocking caches and demonstrated the effectiveness and severity of cache DoS attacks [6], [7], [35]. The work presented here significantly improves the effectiveness of the prior cache DoS attacks by taking advantage of memory address mapping information and HugePage support to create more effective attacks.
Recently, micro-architectural timing channel attacks have gained notoriety, as seen by the Meltdown, Spectre, Foreshadow, and ZombieLoad attacks [20], [23], [31], [36]. These attacks generally work by measuring the timing differences in accessing certain micro-architectural resources (e.g., cache), whose states are altered in such a way to leak secrets. For example, Jiang et al. [13] showed that knowledge of L1 cache bank layouts could be leveraged for a timing channel attack that intentionally generated L1 bank contention. By doing so, they were able to retrieve a full 128bit AES encryption key in less than three minutes. While these attacks target micro-architectural resources, they are different from DoS attacks in that their goal is to leak secrets rather than impacting real-time performance.

CONCLUSION
In this paper, we introduced memory-aware cache DoS attacks that leverage a system's memory address mapping information and HugePage support to induce prolonged cache blocking by intentionally creating DRAM bank congestion. From extensive experiments on two popular embedded multicore platforms, we show that our new DoS attacks can generate significantly higher timing impacts to cross-core victim tasks compared to prior cache DoS attacks. For future work, we plan to launch our attacks on platforms that employ more sophisticated XOR address mapping schemes and evaluate their feasibility on server and cloud-based platforms.