Talk:Row hammer/Archive 1

Proper noun+move to "rowhammer"
As a proper noun, I believe Rowhammer/Row Hammer should always be capitalized. And Google has 10x as many hits for "rowhammer" as for "row hammer", so I suggest moving the article to Rowhammer and using "Rowhammer" instead of "Row Hammer" everywhere in the article. And "Rowhammer" in one word just seems more natural to me too :). Thue (talk) 15:48, 11 March 2015 (UTC)


 * Hello! Hm, I've chosen "row hammer" because that's how Intel calls it in its (scarce) documentation, and I'd say that it's closer to not being a proper noun so no capitalization should be required, just as it's the case for material design, for example. &mdash; Dsimic (talk | contribs) 17:18, 11 March 2015 (UTC)


 * Material Design should absolutely also be capitalized as a proper noun. Looking at the first two pages of Google search, all results but the Material Design homepage and Wikipedia capitalize it. It is just a basic rule of grammar.
 * More importantly than Intel, it seems that the original paper used "row hammer". But that was mostly as a description, whereas "Rowhammer" seems to be the actual unique proper noun it has morphed into. IMO there is critical mass to acknowledge the change from description ("row hammer") into a proper noun ("Rowhammer"). And if something has a proper noun, I think the Wikipedia article should use it - a concept having a unique name is good for descriptions. Thue (talk) 19:55, 11 March 2015 (UTC)


 * I must say I still disagree; please see and WP:LOWERCASE for a related discussion and one of our guidelines.  To me, row hammer is more of a concept rather than a specific thing that would require a proper noun.  The fact that many websites capitalize it as Row Hammer is a quite widespread trend in general, as various webpages, companies or people simply bring more "awe" into things by making them look like proper nouns, while they usually represent rather general concepts.  However, I'll give this a few more second thoughts a bit later, right now I have more work to do on adding more content to the article. :) &mdash; Dsimic (talk | contribs) 20:19, 11 March 2015 (UTC)


 * Uhh, obviously Material Design is a proper noun, even though Feynman1918 claims otherwise on the talk page. He is simply completely and obviously wrong. Thue (talk) 19:36, 12 March 2015 (UTC)


 * Rather than plainly asserting that such things are "obvious" and appealing to popularity (Google results), you should try to rationalize your viewpoints. I'm not up to speed about capitalization rules in English, but just from having seen how lots of discussions about capitalization end up on Wikipedia, I'm siding with Dsimic for now. -- intgr [talk] 20:08, 12 March 2015 (UTC)


 * I already gave the actual arguments in my reply to Feynman1918 on talk:material design. I believe the answer is obvious given my arguments. Thue (talk) 22:15, 12 March 2015 (UTC)


 * Similarly to how I've in, there isn't a single object/entity we can point a finger at and say "that's the Row Hammer".  Row hammer is more of a concept, rather than a specific entity; moreover, row hammer is the observed type of effect that causes bit flips (which may be called hardware bugs) and opens the path for a brand new attack vector type that leads to exploits.  There's no single entity called "Row Hammer" in that whole path.
 * In the English language, pretty much everything can be capitalized; for example, labels in software dialogs, section headings, even ordinary phrases to make them stand out more. However, Wikipedia takes a more conservative approach; a good example is the way section titles are capitalized in Wikipedia vs. in many other places. &mdash; Dsimic (talk | contribs) 13:11, 13 March 2015 (UTC)

Doesn't actually describe what the thing is about?
I'm reading this page and kinda noticing that it doesn't actually state what rom hammering is anywhere on it,

It states that its a security bug, a hardware quirk, etc. But those are categorizations, not actually describing the thing.

I'm way to high to actually fix this myself, but somewhere between the first two paragraphs of overview should at least describe the process. even something as simple as "row hammering is the processing of accessing/reading a row repetitively to induce disturbance errors in near by rows" Kyleshome (talk) 11:10, 13 March 2015 (UTC)


 * Hello! Well, I'd say that the article clearly says what row hammer is; here's what the lead section says:
 * Row hammer (also written as rowhammer) is an unintended side effect in dynamic random-access memory (DRAM) that causes memory cells to leak their charges and interact electrically between themselves, possibly altering the content of nearby memory rows that actually were not addressed in the original memory access.
 * So, it causes changes in adjacent DRAM rows, and that's explained more than once further down the article. &mdash; Dsimic (talk | contribs) 12:24, 13 March 2015 (UTC)


 * On second thought, section did require some additional wording to better tie it all together, so got it .  Please check it out and let me know if further clarification is needed. &mdash; Dsimic (talk | contribs) 14:36, 13 March 2015 (UTC)

Project Zero native attack - x86-32?
My reading of the Project Zero attack is that they demonstrated the attack using the machine in 32-bit mode. Attack on a 64-bit OS should be possible - but much harder, due to the greater entropy in ASLR. — Preceding unsigned comment added by Streapadair (talk • contribs) 14:12, 19 March 2015 (UTC)


 * Hello! Both Project Zero's exploits (ab)use the x86-64 architecture; here's a quote from one of the references (emphasis added):
 * We found various machines that exhibit bit flips (see the experimental results below). Having done that, we wrote two exploits:
 * The first runs as a Native Client (NaCl) program and escalates privilege to escape from NaCl's x86-64 sandbox, acquiring the ability to call the host OS's syscalls directly. We have mitigated this by changing NaCl to disallow the CLFLUSH instruction. (I picked NaCl as the first exploit target because I work on NaCl and have written proof-of-concept NaCl sandbox escapes before.)
 * The second runs as a normal x86-64 process on Linux and escalates privilege to gain access to all of physical memory. This is harder to mitigate on existing machines.
 * Thus, the 32-bit mode hasn't been involved. &mdash; Dsimic (talk | contribs) 14:50, 19 March 2015 (UTC)

Code formatting
At 29em the code gets wrapped over two lines for me (I'm using DejaVu Sans Mono, the default monospaced font on most Linux systems). I assume this is unintentional. Is there anyway to get the box to resize to contents instead of specifying a fixed with?

Also, since several months the  tag has been putting inline code inside a hideous box. Although this should arguably be fixed in the global style sheet... —Ruud 18:07, 6 August 2015 (UTC)


 * Hello! Thanks for letting me know, please let me check how to actually fix that width issue.  Oh, I hear you about the box produced by , back at the time when it appeared I was almost disgusted, :) but got myself accomodated to it over time so it doesn't bother me any more.  Maybe it's been decided that the box makes code fragments more readable or more easily spotted, who knows. &mdash; Dsimic (talk &#124; contribs) 18:16, 6 August 2015 (UTC)


 * Could you, please, check what the table looks like now?  should resolve the wrapping issue. &mdash; Dsimic (talk &#124; contribs) 19:03, 6 August 2015 (UTC)


 * Perfect! Spoke too soon (guess I didn't reload the page or didn't look close enough)... The two longest lines still wrap. —Ruud 19:12, 6 August 2015 (UTC)


 * Poked around a lot, ending up in asking for help on . Hopefully we'll find a good solution.  There also seem to be some recent changes with the syntax highlighting, resulting from T85794. &mdash; Dsimic (talk &#124; contribs) 22:06, 6 August 2015 (UTC)


 * ✅, the layout . All that wouldn't be possible without 's dedication to resolving all kinds of Wikipedia's CSS-related issues. :) &mdash; Dsimic (talk &#124; contribs) 18:41, 27 September 2015 (UTC)

Refresh rate
Yesterday I installed a BIOS update that supposedly reduces the risk of exploitation of rowhammer by doubling the refresh rate of my laptop's memory. I remember reading somewhere else that doubling the refresh rate might not be sufficient and that it would possible need to be increased by a factor of eighth to fully mitigate the issue, but that this would be prohibitively much. I assumed I read that in this article, but as I can no longer find it anywhere here, apparently not. Does anyone else know where I might have read this? As it would make an interesting addition to this article.

The security advisory also claims, in contrast to this article, that ECC RAM is not know to be affected. —Ruud 17:37, 6 August 2015 (UTC)


 * Hello! The factor of eight hasn't ever been in the article and I unfortunately can't remember reading that anywhere; I'll try to research that a bit further.  Regarding the Lenovo's claim that ECC memory prevents row hammer from occurring (which is somewhat similar to what Cisco said), other rather independent sources state exactly the opposite –  please see page 32 in this PDF, and page 8 in this PDF.  Although it would totally be a WP:OR, I'd say that Lenovo tries to calm down customers that shelled out big bucks for rather expensive ECC-equipped systems. :)  Most importantly, Lenovo doesn't say whether it's about "plain" SECDED ECC or more advanced variants such as Chipkill and its equivalents, so I'd take their statement with a grain of salt. &mdash; Dsimic (talk &#124; contribs) 18:34, 6 August 2015 (UTC)


 * They also seem to contradict themselves, as they also list the ThinkStation D30 as affected, which I'm fairly sure ships with DDR3 ECC memory. Only the P500 and up are listed as not affected (they use DDR4 ECC memory). My laptop still doesn't pass Google's double-sided hammering test, so I guess doubling the refresh rate isn't all that effective either. —Ruud 19:31, 6 August 2015 (UTC)


 * Well, it's very important to keep well paying customers on their primrose paths. :) Please have a look at  I've made to the article  –  you were right, only the much higher memory refresh rates (roughly seven times higher) are found to bring the rate of disturbance errors close to zero. &mdash; Dsimic (talk &#124; contribs) 20:39, 6 August 2015 (UTC)


 * Hi! just stumbled upon this article which mentions factor eight as a possible countermeasure: . — Preceding unsigned comment added by 83.78.239.253 (talk) 11:57, 3 January 2016‎ UTC


 * Hello! Thank you for pointing out that article, but it seems rather vague to me from the standpoint of using it as a reference for the eightfold refresh rate increase.  Such an increase is mentioned just as a potential countermeasure without providing any test results etc. &mdash; Dsimic (talk &#124; contribs) 12:11, 3 January 2016 (UTC)