Multicore Denial-of-Service Attack

In a paper from USENIX 2007 by Microsoft Researchers Onur Mutlu and Thomas Moscibroda present a working “denial of service” attack for multicore processors. The idea is simple: since there is no fairness or security designed into current DRAM controllers, it is quite feasible for one program in a multicore system to hog almost all memory bandwidth and thus reduce or deny service to the others. There is no direct attack on software programs, just stealing the resources that they all need to share for all to work.
The attack is baesd on the following:

• Several cores share the memory controller(s) — quite likely, since there is not room for more one controller per core in >2 core machines. The limitation is both because memory controllers are large and complex beasts, and because the pins needed for each memory interface makes it hard to have more than a few on a single chip. While the real estate for processors easily lets us put 4, 8, or 16 cores on a chip today.
• Modern DRAM controllers are not a strict fifo queue, but attempt to optimize memory bandwidth by prioritizing accesses that are directed to the currently open rows in the banks in the available DRAMs.
• The scheduling strategy used today (as they claim) can be easily monopolized by a thread with a high rate of memory accesses and good sequential locality. There is no attempt to provide fairness between cores or programs.

A simple stream benchmark doing a sequential read through a large array is a simple example of what they term an MPH — Memory Performance Hog. In experiments on real hardware and in simulation they show how it can kill the performance of simultaneously executing programs with somewhat more random access patterns.

So what to make of this?

First of all, this is a real attack, in the respect that this sort of thing can and do happen on current hardware with current software out in the field. How dangerous it is in practice is hard to tell, but it could be an issue for various cases where users are sharing a computer. A bit like the old “fork bomb” on Unix systems. I remember being thrown out of shared Solaris machines a few times due to these (several times unintended by beginning Unix programmers making honest mistakes).

It is more interesting in the context of embedded systems and integrated modular avionics (IMA). As I stated in a few earlier blog posts(63 and 58) I think that the best way to host multiple different applications on a multicore processor is to partition applications sparially across cores. This should be more efficient, simpler, and safer than sharing all the cores across partitions using time sharing.
However, this attack does reflect critically on that idea: if it is this simple to hog the memory and thus kill performance of other cores and applications, it might not be particularly safe to have each core run an independent set of applications of different criticalities. It does mean that in order to ensure performance isolation between applications, you will need additional hardware support of one form or the other. Could be a better DRAM scheduler (as the paper proposes), or a static allocation of a DRAM controller to each core (which is likely infeasible due to pin constraints), or DRAM controllers that do a slightly inefficient but safe allocation of a portion of their bandwidth to each core.

In the meantime, maybe the ugly temporal sharing of the entire chip is the “best” way ahead, as it at least is proof against this kind of attack based on parallel execution of partitions.