Talk:Row hammer/Archive 1

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. — 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 Talk:Material design § Title capitalization 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. :) — 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 explained it in Talk:Material design § Title capitalization, 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. — 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. — Dsimic (talk | contribs) 12:24, 13 March 2015 (UTC)

On second thought, Row hammer § Overview section did require some additional wording to better tie it all together, so got it slightly improved. Please check it out and let me know if further clarification is needed. — 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. — Dsimic (talk | contribs) 14:50, 19 March 2015 (UTC)

Code formatting

@Dsimic: 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 <code> 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 <code>...</code>, 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. — Dsimic (talk | contribs) 18:16, 6 August 2015 (UTC)

Could you, please, check what the table looks like now? This additional CSS should resolve the wrapping issue. — Dsimic (talk | 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 Template talk:Syntaxhighlight § Source code wrapping. Hopefully we'll find a good solution. There also seem to be some recent changes with the syntax highlighting, resulting from phab:T85794. — Dsimic (talk | contribs) 22:06, 6 August 2015 (UTC)

 Done, the layout is fixed now. All that wouldn't be possible without Edokter's dedication to resolving all kinds of Wikipedia's CSS-related issues. :) — Dsimic (talk | contribs) 18:41, 27 September 2015 (UTC)

GA Review

This review is transcluded from Talk:Row hammer/GA1. The edit link for this section can be used to add comments to the review.

Reviewer: Cirt (talk · contribs) 06:23, 27 September 2015 (UTC)

I will review this article page. — Cirt (talk) 06:23, 27 September 2015 (UTC)

Thank you very much! I'm here for all questions, suggestions, improvements to the article, etc. — Dsimic (talk | contribs) 15:24, 27 September 2015 (UTC)

Good article nomination on hold

This article's Good Article nomination has been put on hold. During review, some issues were discovered that can be resolved without a major re-write. This is how the article, as of September 28, 2015, compares against the six good article criteria:

1. Well written?:

• NOTE: Please respond, below this review, and not interspersed throughout, thank you!
• Writing quality is good for this level of quality.

2. Verifiable?: Duly cited throughout, no issues here.

3. Broad in coverage?: Goes over major aspects, no issues here.

4. Neutral point of view?: Presented in neutral tone throughout, no issues here.

5. Stable? ONLY ISSUE here -- please explain this recent edit, and why it is not a problem anymore for article stability. Was there a subsequent discussion with the user? Was a compromise reached? Are issues settled satisfactorily?

6. Images?: Two imaged used, both from Wikimedia Commons, both check out okay upon image review.

NOTE: Please respond, below this review, and not interspersed throughout, thank you!

Please address these matters soon and then leave a note here showing how they have been resolved. Within 7 days, the article should be reviewed again. If these issues are not addressed by then, the article may be failed without further notice. Thank you for your work so far. — Cirt (talk) 02:37, 28 September 2015 (UTC)

Thank you for reviewing the article! Regarding these recent edits, as explained in the edit summary of my subsequent edit, they actually didn't bring improvements to the article; the addition also kind of instructed the readers, although that wasn't the primary issue. No new content was added, and having such summary-style lists pretty much goes against the WP:PROSE guideline; if we had a much larger amount of the "summed up" prose, such a list might have been acceptable although that would also be debatable. No discussion was started since my edit three days ago, implying that the restoration of a stable article version has been accepted so the overall article stability shouldn't be affected. — Dsimic (talk | contribs) 03:13, 28 September 2015 (UTC)

Thanks for the prompt response. Passed as GA. — Cirt (talk) 03:24, 28 September 2015 (UTC)

Thank you very much! Would you, please, be willing to suggest a few areas for improvements that might bring the article to the quality level required for a featured article? — Dsimic (talk | contribs) 03:38, 28 September 2015 (UTC)

Some possible suggestions for improvement:

• I'd make "Mitigation" into its own section and place it after "Implications". Possibly rename "Implications" to "Implications and exploits" to get rid of the then last remaining subsection.
• The paragraph breaks in "Mitigation" seem somewhat arbitrary. E.g. no break between "mitigation" by ECC and counters. I think section should also make clear which mitigations are feasible on existing systems (e.g. increasing the refresh rate), which require hardware changes that have been implemented (e.g. pTRR), and which require hardware changes and have not yet been implemented (counters).
• W.r.t. increasing the refresh rate: I believe JEDEC standards require all chipsets to be able to double the refresh rate to 32ms in order to operate correctly in high-temperature environments, but no more than that (which is rather unfortunate as I mentioned in a section above). It might be interesting to mention this. You'd have to dive in some chipset documentation to confirm all this, though.

I'd say the article is otherwise correct, complete and very readable. —Ruud 14:34, 28 September 2015 (UTC)

Those are very good suggestions, thank you! I'll see to have them incorporated into the article in the next few days, and the part requiring digging through the documentation of certain northbridges/IMCs is going to be particularly enlightening. :) — Dsimic (talk | contribs) 14:45, 28 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 [1] 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. — Dsimic (talk | 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 these few edits 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. — Dsimic (talk | contribs) 20:39, 6 August 2015 (UTC)

Hi! just stumbled upon this article which mentions factor eight as a possible countermeasure: [2]. — 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. — Dsimic (talk | contribs) 12:11, 3 January 2016 (UTC)