1. Home
  2. Electronics Design
  3. row hammer
  4. Page 2

row hammer

That is correct, but they are just praying that the computer does what they want, and does not suddenly mess up their data because a bit flipped in the memory. It does not happen often, and it does not always have disastrous undetected results. Probably more often it just makes your program crash with one of those "Microsoft Outlook has stopped working, click here for details" messages boxes that people click away without even reading them. But in some cases it may result in a wrong letter somewhere in an email, that you later attribute to a typing mistake.

You can be sure that Amazon and Dell themselves do not trust their company data to systems without ECC RAM. It is your own decision if you want to do the same.

Reply to
Rob
Loading thread data ...

We use ECC ram and RAID hard drives for business stuff, and back things up brutally.

The worst thing that happpens is that Windows bogs itself once in a great while and has to be rebooted.

I'm not going back to typewriters and carbon paper. Or wet film photography. Or tape and mylar PCB layouts.

Spice is OK too.

--

John Larkin         Highland Technology, Inc 

Science teaches us to doubt. 

  Claude Bernard
Reply to
jlarkin

Assuming the exploit would need to hammer more than one consecutive row, could the board maker do something by swapping some of the address bits?

With different bits swapped in each board model, the exploit would have a tough job.

I know you can't swap just any address lines because that would defeat several kinds of fast addressing modes, but maybe there are some possibilities.

Reply to
Tom Del Rosso

You repeatedly access the (physically!) adjacent row. Or, the rows on either side of the row being attacked.

You'd likely also have to tweek the memory controller's initialization of the devices.

Easier to link the modules in different orders so stuff ends up in different places. Of course, that assumes there is no way that this information leaks in other ways!

Note that you can notice who (task ID) is "current" when the *likely* ECC action takes place. If you're always encountering EDAC problems while "foo()" is executing, then perhaps foo() needs to be 86-ed!

Reply to
Don Y

But there's no reason the physical and logical order of rows has to match.

A few minutes after posting I realized that the RAM makers could do it more effectively than the board makers, by mixing up the order of rows. If every model of chip did that differently the exploit would never work. There is no way to tell what RAM chips are in the system is there? The type of RAM can be seen but not the brand.

Reply to
Tom Del Rosso

Even better - you don't really care.

I have, and do actually run a full regression on certain builds of software. I 100% bit by bit compare the output of the previous to the latest.

I just. Don't. See. Errors. Er, rather, the only errors I see can be traced back to the most recent layer of changes.

An interesting take might be: If I did get an error, chances are, I'd rerun it, and there would be no error.

I realize determinism is boring, but I seem to be awash in it. No neutrino events for me, boyo. :)

--
Les Cargill
Reply to
Les Cargill

You can get all that using "dmidecode":

Memory Device Array Handle: 0x0038 Error Information Handle: Not Provided Total Width: 64 bits Data Width: 64 bits Size: 8192 MB Form Factor: DIMM Set: None Locator: ChannelA-DIMM1 Bank Locator: BANK 0 Type: DDR4 Type Detail: Synchronous Unbuffered (Unregistered) Speed: 2666 MT/s Manufacturer: A-DATA Serial Number: 745C0300 Asset Tag: 9876543210 Part Number: Rank: 1 Configured Memory Speed: 2666 MT/s Minimum Voltage: Unknown Maximum Voltage: Unknown Configured Voltage: 1.2 V On Linux you need to be root to run dmidecode, so it would still be hard for an attacker to get that information.

--
  Jasen.
Reply to
Jasen Betts

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.