• 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.

Freescale demonstrated a hardware reference platform with a number of security features for future mobile devices, its i.MX31 and i.MX31L multimedia applications processors. Based on the Arm 11 core designed by Arm Holdings, the chips have a run-time integrity checker that verifies the digital signature of code before executing it. This can help stop malware sneaking onto the device — although it could also be used to lock down a mobile device and prevent the installation of third-party applications, much as Apple has attempted to do with its iPhone.

Prototypes are often designed with additional standard circuitry to make it easier to observe their behavior under test. Probes applied to that circuitry, known as a JTAG interface, can even be used to issue debugging instructions to the microprocessor. The connections for the prototype’s JTAG interface often survive — in different positions on the circuit board — right through to final production. Identifying where these points were located on Apple’s iPhone became one of the goals of those trying to unlock the devices as access to it might have allowed them to debug Apple’s security code.

This is the same concern that was expressed in Strombergsons comments to my post on hardware support for parallel programming. Basically, that remnants of debug support for the development phase can be used in deployment to hack into the device.

And that is pretty hard to get around if you assume you want to do debugging on the device. Which I guess is needed for almost all devices, if nothing else in order to analyze performance on actual hardware. Otherwise, I do believe that virtual prototype platforms and simulators like Simics is a key technology to develop safe applications safely — using a virtual system for debug, you have no need for debug backdoors on the final hardware. That backdoor is only there in the virtual hardware, not in the physical manifestation of the hardware. Of course, it is then key that the virtual debugger cannot be used by bad guys to break into the software. I think that can be worked around by making it impossible to get a complete system image off of a target system, which is back to physical security.

I think we need some kind of thinking akin to the key tenet of crypto theory, that information should be safe even if all algorithms and mechanisms involved in encrypting it is known. The secrecy of the key is all that is needed. In the same vein, we need to ensure that a piece of software running on a particular piece of hardware is protected against access and intrusion, if the attacker gets access to the source code of the program and a simulator for the hardware or even debug hardware. There has to be some kind of “key” mechanism that can be used to ensure this.