Following previous post related to RowHammer JS, following is a discussion on attack surface. I completed these notes as part of work in University of Oxford and towards GCHQ accreditation. All comments are my own.
Discuss the attack in terms of changes in the attack surface between design and implementation, What was additionally introduced and to what extent could this have been visible in the design phase ?
With respect to CPU cache L1, L2 and L3 (intel specific in the context of this paper); the design of such cache is mainly focused on performance, in the context of this paper authors where able to leverage L3's inclusive cache design principle that included L1 and L2's data; in addition to L3 being shared among all core's, net result is when L3 is purged L1 and L2 are also purged for the relevant core thus making it 'easier' (used lightly) to invoke a cache miss. In this context of CPU cache, it would have been more difficult or at least less visible at both design and implementation phase for row hammering to be visible during the design. In the context of this paper, cache was used from an observation perspective i.e. a timing attack; by monitoring timings for row access it was possible to determine a cache hit v's a cache miss. A cache hit vs a cache miss tends to leak information, in this case the information leaked is whether an address is cached or not, it can be quiet challenging to determine such a cache hit v's cache miss, however if you have enough samples a pattern emerges. Though as noted by , vendors have been aware of row hammering concerns since at least 2012.
 Yoongu Kim Ross Daly Jeremie Kim Chris Fallin Ji Hye Lee Donghyuk Lee Chris Wilkerson Konrad Lai Onur Mutlu, Carnegie Mellon & Intel Labs
Flipping Bits in Memory Without Accessing Them: An Experimental Study of DRAM Disturbance Errors
 Seaborn & Dullien http://googleprojectzero.blogspot.ie/2015/03/exploiting-dram-rowhammer-bug-to-gain.html
 Daniel Gruss, Clementine Maurice, Stefan Mangard
 Maurice & Gruss rowHammer.js presentation