MemTest86 v6.2.0 released - 8/Sept/2015

[keith]

We are pleased to announce the release of MemTest86 V6.2 which includes several new features and various enhancements/bug fixes.

Like previous releases since v5, the MemTest86 V6.2 image supports dual booting (UEFI/BIOS). On machines that don't support UEFI, the older V4 BIOS release of MemTest86 will be automatically booted. MemTest86 V6.2.0 has been digitally signed by Microsoft and therefore is compatible with Secure Boot.

What new in V6.2.0 compared to V6.1.0

• Due to the high number of failures reported for the Hammer Test (Test 13), the algorithm was revised to perform 2 potential passes:

1. Row pairs are hammered at the maximum hammer rate. (ie. no delays between each row pair hammer)
2. Row pairs are hammered at a lower hammer rate (200K per 64ms, as determined by memory vendors as the worst case scenario)

1. If memory errors are detected in the first pass, error details are not immediately displayed to the user and the second pass is started. If errors are detected in the second pass, they are reported as normal.
2. If errors are detected in the first pass but not the second pass, a warning of potential high frequency bit flips is displayed to the user.
3. The premise behind this revision is to better inform users of the significance of errors detected in the Hammer Test, as opposed to a strict PASS/FAIL result. Although errors detected in this test are real errors, the conditions needed to induce these errors occur only very rarely in normal PC usage, and should not be of concern to most users. Therefore, a warning rather than an outright failure would ensure the user is aware of the issue and be able to take the necessary measures to mitigate the issue.

1. The details of the errors that were detected in the first pass of the Hammer Test but not during the second pass can be displayed in the report by specifying the configuration file parameter 'REPORTNUMWARN'. This parameter represents the maximum number of warnings to display in the report file.
2. New configuration file parameter 'AUTOMODE' for full automation. Enabling this parameter shall result in the following:

1. Splash screen is skipped and the tests are started immediately
2. When the tests are completed, the report is saved to disk automatically
3. System is rebooted

1. + 7 other fixes/enhancements (Full list of changes can be found here)

Download links
The Pro Edition can be purchased from our sales page, either as USB image files that users can install on their own USB flash drives, or an already-made USB flash drive with MemTest86 pre-installed.

The Free Edition can be downloaded directly from our download page:
http://www.memtest86.com/download.htm

Version History
The full 20 year release history of MemTest86 can be found here,
http://www.memtest86.com/support/ver_history.htm

Pro Upgrades
If you purchased the Pro edition of V5 or V6, it is a free upgrade to V6.2 Pro. You can use the same download link to get V6.2.

[dsullaustin]

Watering Down Rowhammer Failures is a Mistake

Dear Passmark Team,

I have been using Memtest86 for the past 10+ years. I have always respected it as an independent, freely available, third party tool.

This latest 6.2.0 release, however, is bending over for the memory vendors who have been trying to hide this problem for years. This problem is to DDR as to what the floating point problem was to Pentium. Just because memory vendors reply arrogantly is no reason to change the test outcomes. Data corruption is data corruption. And worst case, obviously, is any legal code that causes the system to corrupt data--not their opinion of worst case. We have seen it from Kim's code, two variations from Google that can take control of a machine (security issue), and at least one version that works on simple javascript.

A test that reveals data corruption that could crash the OS, write bad data to drives, and/or leave an open security hole is simply not acceptable. The only reasonable mitigation is DRAM replacement or BIOS updating that allows for more frequent refreshing.

In my opinion, helping the industry hide the severity of this problem is outside the spirit of the original Memtest86 charter. To identify hard to find bugs in the shortest period of time.

I hope that you guys reconsider. And in fact, I'd like to see more emphasis in the area of Rowhammer type tests. I'd rather know more about system failures and be my own judge.

-Dave

[David (PassMark)]

It is a balancing act.

The row hammer algorithm is artificial, especially the cache flushing part. So having similar memory access patterns in real software isn't common. It isn't impossible either however.

I haven't seen any variant of it that can work effectively in Javascript however. I doubt it is possible to generate high row hammer rates from Javascript (as you don't have the low level access to flush the case, or get the system information to determine the possible row sizes).

Scaring people unnecessarily isn't a good thing. We don't really want to report errors that the user will never encounter. Especially novice users who don't have a deep understanding of the situation. We think the 6.2 changes represent a reasonable attempt at providing accurate results.

Also you can still see all the row hammer errors by setting the REPORTNUMWARN flag in the configuration file (basically keeping the original behavior, except for the labeling change).

[dsullaustin]

Disagree 100%

David,

I respectfully, but strongly disagree. Please see my comments below:

"It is a balancing act.

The row hammer algorithm is artificial, especially the cache flushing part. So having similar memory access patterns in real software isn't common. It isn't impossible either however."

This new Rowhammer test is no more artificial than any other test in your list. If it's written using code that can be written and compiled then it is real. How can you call this artificial? As pointed out in earlier documentation of Rowhammer, it's also observable using semaphores, which do A LOT of cache flushing natively.

"I haven't seen any variant of it that can work effectively in Javascript however. I doubt it is possible to generate high row hammer rates from Javascript (as you don't have the low level access to flush the case, or get the system information to determine the possible row sizes)."

Have you been on vacation the past couple months?

http://motherboard.vice.com/read/rowhammerjs-is-the-most-ingenious-hack-ive-ever-seen

"Scaring people unnecessarily isn't a good thing. We don't really want to report errors that the user will never encounter. Especially novice users who don't have a deep understanding of the situation. We think the 6.2 changes represent a reasonable attempt at providing accurate results."

Yes, scaring people about a real hardware problem that can be a security exploit is not necessarily a good thing. Especially for the memory and system vendors who don't want to address this issue or return damaged product. Since Kim's discovery, there have been 3 real world exploits of this problem PUBLICLY announced. How many hackers are working on this in private? I'm willing to err on the side of caution and guess quite a few.

This is a political issue for sure. But as a diagnostic, most of us simply want to know pass or fail. And this "balance" you speak of seems lopsided towards the hardware folks.

-Dave

[David (PassMark)]

I skimmed the JS paper. The researchers found one machine (just one) that exhibited an error with a single version of Firefox. To do this they also needed to run a native application outside of the browser to track memory accesses from the Firefox process, then hard code the addresses into the script. One machine with a RAM error doesn't make for a global crisis.

They didn't test other browsers, they didn't test any AMD systems & they failed to provoke the problem on the other two Intel systems they tested without manual modification to the BIOS settings to slow the refresh rate. They also failed to mention the obvious countermeasures of ECC RAM and the pTRR/TRR (Pseudo Pseudo Target Row Refresh) solution which is already be implemented in newer server CPUs.

They also pointed out that native code (like MemTest86) provokes errors at a rate which is at least an order of magnitude higher than JS. So MemTest86 should still easily pickup machines that are vulnerable to the JS implementation.

(And again, you can still have the old behaviour, with the REPORTNUMWARN flag)

[rnsjunkmail]

I think Third I/O's comments on this subject are highly relevent... http://www.thirdio.com/rowhammer.pdf

I would like to see PassMark comment on the current state of Row Hammer... it would also be an idea for PassMark to leave users the option of configuring it to anonymously uploading data about errors encountered that could be used statistically to enhance MemTest86 and help the developers id which tests fail most often and therefore which they need to enhance to help users save time and narrow down the errors encountered ( just an idea).