Exploiting the DRAM Rowhammer Bug To Gain Kernel Privileges 180
New submitter netelder sends this excerpt from the Project Zero blog:
'Rowhammer' is a problem with some recent DRAM devices in which repeatedly accessing a row of memory can cause bit flips in adjacent rows. We tested a selection of laptops and found that a subset of them exhibited the problem. We built two working privilege escalation exploits that use this effect. One exploit uses rowhammer-induced bit flips to gain kernel privileges on x86-64 Linux when run as an unprivileged userland process. When run on a machine vulnerable to the rowhammer problem, the process was able to induce bit flips in page table entries (PTEs). It was able to use this to gain write access to its own page table, and hence gain read-write access (PDF) to all of physical memory.
Impressive (Score:5, Insightful)
Don't have much more to say than that's an impressive exploit.
Re: (Score:2)
I'll second that, and add that I suspect this could also be used for hypervisor/sandbox escapes on practically *any* platform that doesn't use ECC memory.
Re:Impressive (Score:5, Informative)
And, if you had read the actual paper, you'd see that ECC isn't proof against it either
Re: (Score:3)
so when they said:
We also tested some desktop machines, but did not see any bit flips on those. That could be because they were all relatively high-end machines with ECC memory. The ECC could be hiding bit flips.
they actually said that ECC doesn't matter?
I guess we read differently.
Re:Impressive (Score:4, Informative)
I see - you were looking at the PDF link, which is more theoretical. yes, if you can get two or more bits to shift inside a 64-bit chunk, then ECC doesn't help. There's got to be a low probability of that actually happening though - the Google Project Zero wasn't able to make it happen with ECC at all.
Re: (Score:2)
Re: (Score:2)
Yes, it would be detected, but it could not be corrected. It would likely crash the software with a memory fault, in which case you would have a denial of service attack rather than defeating protected memory and allowing something access from outside the box.
Not good, but better than complete privilege escalation.
Re: (Score:2)
It would generate a report listing the error and may or may not halt the machine depending on how that is set.
Re: (Score:2)
(not 64, ECC in x86 works on 32 bit words)
There's no 36,32 hamming code that can give full SECDED. Intel and AMD use 72,64. Probably everyone else too, since x72 memory is so common.
Re: (Score:2)
For a while now 4 bit chipkill has been supported as well which I think takes 144,128.
Re: (Score:2)
That depends on how you do it though. Through some smart row walking you could probably increase the frequency a lot. And then you have ASLR complicating things from both ends(though I think it could be used to help in an attack actually)
Re: (Score:2)
ECC != parity check. It can detect two errors and correct one.
Re: (Score:2)
Reporting on the event or halting the machine upon detection of a double bit error *is* better than missing it completely and some triple bit errors would be detected as well. If chipkill ECC was being used which is commonly available, then up to 4 bits within a nibble boundary would be detected and corrected.
Re: (Score:2)
Nowhere did I say that ECC didn't matter. I just said that ECC isn't guaranteed to protect you. It just reduces probability.
Re: (Score:2)
It makes it completely ineffective when there is ECC. If three bits haven't flipped then the error will be reported and logged and probably blasted out on every console. The likelihood of this attack being detected well before it is exploited is extremely high. If it's two bits then either the application will be killed or the machine will halt, most likely the latter.
Re: (Score:2)
You must have read a different paper than me.
ECC on a decent machine would make this attack almost impossible.
For one thing, the memory controller will likely support memory scrubbing, which will detect and correct single memory errors long before enough bits are flipped for ECC to no longer detect the corruption. ECC will typically correct one bit error and detect two bit errors. Since the chance of a bit flipping is random and takes thousands of operations, the chance of having three bits flip and not be
Re: (Score:2)
I've wondered for a long time why unregistered ECC hasn't become the default on desktops while reserving buffered DIMMs for servers.Mass production would likely erase any price advantage of non-ECC memory.
Re: (Score:2)
Adding the extra 8 bits per 64 bit line would always raise the price 12.5% although that could be insignificant. There are also some boot time issues because memory has to be initialized which takes time and adds complexity.
I am inclined to blame Intel as far as why ECC is not more common since they use t
Re: (Score:2)
Every implementation I have seen in recent times has always performed error correction as well as detection. You only need 7 bits to correct one bit error out of 64-bits. With 8 bits you can detect two bits and correct one bit. ECC DIMMs are typically 72-bits wide. LPDDR4 also includes support to detect and prevent this sort of attack.
Re: (Score:2)
And try flipping three bits before you try and access the memory. If it's not exactly three bits then the memory corruption will be detected, and if it's one bit it will be corrected. In any case, if it is not three bits when the memory is accessed then it will be reported. Also, high end hardware can do memory scrubbing, where the memory controller periodically reads all of the memory in the background to detect and correct single bit errors before they are a problem. See Memory Scrubbing [wikipedia.org].
Re:Impressive (Score:4, Insightful)
Re: (Score:2)
I would be happy with giving a single bonus if some EE engineers or physicists can explain how this exploit works. Right now we only know what it does -- flip bits in some memory locations by writing to other memory locations.
Re: (Score:2)
Are you sure that's the case? If what you say is true, the adjacent rows would drain charge and the 'one' bits in the
Re: (Score:2)
ECC errors do not have to halt the machine. They can just be reported.
Re: (Score:2, Informative)
It's a hardware problem, not a software problem.
Re: (Score:2)
The desire to believe in the infallibility of your chosen tools leaves you open to attack. What is that word again?
American.
possible iOS Exploit? (Score:3, Interesting)
Re: (Score:2)
NSA memory controller hack (Score:2)
Geez, who knew that writing 'NSA' to 0xdeadbeef over and over would give you kernel access? Those NSA guys really broke into everything.
ECC Memory (Score:5, Interesting)
Yet another reason to push shared providers for ECC memory. The error correcting memory is so far not vulnerable to this attack, all the researchers that have tried it report that ECC memory identifies and corrects the corruptions. Of course some attackers may have found a way, but ECC minimizes the risk
Amazon says it uses ECC in their AWS machines [amazon.com], but other big hosts like Equinix say that ECC memory is "available". Be careful about your hosting, folks.
Re: (Score:3)
Yes, you beat me to it. A correctly-configured ECC motherboard with real ECC memory would defeat this. Watch out for fake ECC memory that just simulates the correction bits.
Once memory starts being vulnerable to row interference, having a machine without ECC becomes much more dangerous, regardless of this exploit.
Re: (Score:2)
Do you have an example of this fake ECC memory that interested parties should avoid?
Re: ECC Memory (Score:5, Interesting)
I hadn't heard of this either, but a quick google turned up a description of false parity RAM: http://en.wikipedia.org/wiki/R... [wikipedia.org]
TLazy;DR: To save cost where parity RAM was required by the hardware but not by the operator, modules existed that would calculate the parity bit upon reading the RAM, rather than storing the parity bit. I don't see any evidence that this type of module ever existed for ECC though.
To make sure memory is ECC, it's probably sufficient to count the memory chips on a DIMM. If there are 9 or 18 (or even 36, if it's a particularly large DIMM) identically-marked chips, that's ECC. If there are 4, 8, 16, or 32 chips, then it's probably not. If one of the chips is marked differently than the others, it might be a little more complicated; it might be possible that it's a different memory chip (e.g. if there are 4 x16 memory chips, you'd only need one x8 to get a x72 ECC DIMM, so that last chip would be different). But it's also possible that it's buffered/registered memory, and the different chip is the buffer/register.
And an aside on the topic of buying RAM for yourself:
In general, I'm not a fan of cheaping out on memory. I did computer repair for a while, and it shocked me how many problems were caused by bad RAM - from the obvious ("my computer crashes every time I boot it") to less obvious ("every few days, an application crashes") to the rather insidious ("it was running fine, and now I can't mount my hard drive any more"). It got to the point where, when a computer came in with nonspecific symptoms like that, I'd open up the computer and peek at the RAM chips first. If they had no recognizable manufacturer, they were certainly garbage. If they were recognizable but not top-tier, they probably needed some stress testing on our RAM tester. And if they were the good stuff (Samsung always had my vote there, though it's hard to find because they don't sell directly to consumers), then it was probably something else.
That's also where I learned that things like memtest86 or other software diagnostic tools were basically useless too. Only the absolute worst memory would fail a test, even a looped test run for days. Most bad RAM was marginal - after all, it probably passed some manufacturing tests. We had a rather expensive (~$4k-8k) box that would test memory, doing things like varying the supply voltage or self-heating the RAM. When RAM is installed in your PC, you're still limited by the hardware - i.e. the voltage regulator and the memory controller - which probably keep the memory as close to nominal conditions as possible. Obviously, those machines are rather hard to come by, so you have to make do with software tests instead - but a pass on those just means I can't prove it's bad; it doesn't mean the memory is good. Even if I pass all memory testing, I'll still swap/remove/replace DIMMs in an attempt to find which one is bad, because it's often not obvious.
Re: (Score:2)
In the days of the AMD586, it was common for mother boards to be sold with fake ECC. There was actually a "fake ECC" chip soldered where the ECC should be. Often, these boards had defective RAM in too, but would pass the BIOS fake memory test! Memtest86 was written because of these boards.
I bought one myself and was astonished that it was cos
Re: (Score:2)
16GB (as 2x8GB) of ECC will cost you at least $160 for the absolute bottom of the barrel. The same 16GB of non-ECC goes for just about $100. That gives you a 60% markup for only 12% more chips. Really, it surprises me we don't see more fraud like that.
Re: (Score:2)
Re: (Score:2)
It's chipset and processor support, actually.
Intel, for example, typically mandates ECC on the Xeon line (modern CPUs ha
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
You can't even get no-name sticks of non-ECC labelled in Chinese for that. That can't count as a real price, can it?
Re: (Score:2)
Okay, I admit it, I don't get the punchline. I even added one to the cart expecting that as the price per stick (even then, unbelievably low, but maybe for tested pulls), but no, $79 for the whole bulk pack, new???
You can't even get no-name sticks of non-ECC labelled in Chinese for that. That can't count as a real price, can it?
Sure. You just have to pay with bitcoin in advance. You know, just in case you're not a reliable purchaser.
Re: (Score:2)
can you think of a way to do those tests with less cost?
Re: (Score:2)
The place I used to work used to offer it as a service for $5-10 per SIMM/DIMM. If you can find a local shop that has such a tester, maybe they'd do the same. Otherwise, it's probably not terribly likely to get a low-cost solution, since the volume of such testers is pretty small.
Re: (Score:2)
The problem with the software only test is that it does not verify the operating margin in timing, voltage, and temperature. If the motherboard supports it, then raising the memory operating frequency by say 10% and lowering the DRAM operating voltage by say 10% and *then* running the software only test like memtest86 or maybe the Prime95 stress test should work to detect marginal DRAM.
Re: ECC Memory (Score:5, Funny)
Now that's insideous!
It takes 2 bit changes to change 'i' to 'e', so your problems are worse than you thought...
Re: ECC Memory (Score:4, Informative)
In the paper, they actually state that ECC isn't entirely proof either, because you can get multiple bit errors as per their testing. SECDED will be defeated by that. Chipkill might work.
Re: ECC Memory (Score:4, Interesting)
Wouldn't it be better design to put ECC into the memory controller, and arrange the chips to support ECC? That is: physically wire the memory chips and the memory bus to write far from each other (64 chips = interleave every 1 bit across all chips; 32 chips = interleave 2 bits per chip, starting on high bits in addressing so you put them half a chip's distance away from each other), physically protecting against chip-local anomalies. Have the MMU perform a single rotation, logically reserving an amount of RAM on each slot to carry ECC for the previous slot. Write ECC bits to those areas.
Doing it in this way provides zero-cost physical isolation of single-chip memory errors (it's just the wiring layout), while also isolating the ECC from its corresponding module (avoiding RAS/CAS thrashing, allowing simultaneous access to the ECC bits and the corresponding RAM). It lets you pop in an ECC chip and use ECC, or pop in a non-ECC chip and sacrifice 12.5% of your RAM to error correction. That's a lot of RAM: on an 8GB system, it's almost 1GB.
Re: (Score:2)
I can't see how it would be possible to defeat ECC.
The attacker would have to construct a write that affects the desired bits in the row-to-be-hammered and has check bits that affect the row-to-be-hammered's check bits such that the altered row is validated. This is probably nigh impossible to do in all but a select few constrained cases.
Re: (Score:3)
ECC might be able to help the attack. If you know the state of memory and the associated ECC values you would like and can calculate a designed bit pattern with the same ECC that meets the requirements, you may be able to get the ECC hardware to flip the bit for you as you hammer bits that don't matter as much.
Hammering memory to induce writes where they shouldn't happen has been done for decades. It was used back in the days when you needed high voltages to do writes in eeproms when people found out that
Re: (Score:3)
It's possible, but very unlikely.
Rowhammer is not new - it's been known since the 90s since it affects NAND flash memory as well (the same stuff in an SSD) - here there are
Re: (Score:2)
ECC is able to correct one error, but find more than one. If by some strange probability you were able to shift 2+ bits in the same 64-bit chunk of DRAM, ECC would detect it, but just mark it as errored rather than accept what the value is.
It would more likely be a denial-of-service attack rather than being able to manipulate values. The fact that Google's "Zero Labs" guys couldn't make it happen on ECC systems speaks to the probabilities though - ECC may be enough of a protection until the problem gets s
Re: ECC Memory (Score:5, Insightful)
It has yet to be established whether hammer techniques can result in a correct data+ECC pattern. If so, it should be possible to permute the memory in a way that defeats this, either on the memory module or the memory controller.
That would make a good research paper for someone.
Re: ECC Memory (Score:5, Informative)
When you write to a row of memory, it's ECC bits are written to too by the memory controller, which are next to the other ECC bits.
Re: (Score:2)
other big hosts like Equinix say that ECC memory is "available"
I suspect they'd change that policy in a hurry if people started using this for hypervisor escapes.
Re: (Score:2)
I was looking at motherboards and even finding ones that support ECC is difficult, unless this is one of those situations where any motherboard works as long as the CPU supports it.
As far as I understand it, most AMD processors do support ECC, and Intel only supports it in their upper-end products (artificial restriction to segment the market - i7/Xeon/etc). What I don't understand is where the motherboard fits in.
Heck, Newegg doesn't even track that as an option on their product selector.
Rowhammer in MemTest86 & on Slashdot (Score:5, Informative)
It is worth noting that the row hammer issue isn't new. It as been known about for some time. Including this old Slashdot post
http://hardware.slashdot.org/s... [slashdot.org]
There has been an implementation of row hammer testing in MemTest86 V6.0 for over 6 months now as well. MemTest86 implements just the single sided hammer, whereas Google used a double sided hammer.
http://www.memtest86.com/ [memtest86.com]
While the double hammer might produce more RAM errors, this pattern of memory accesses isn't very likely to occur in real life software. So is of limited use as a RAM reliability test.
What is new in this report is the fact that they manipulated the RAM bit flips to turn them into an exploit. Something that was previously speculated on but considered too hard to implement.
What they didn't show however is any results from desktop machines. All their testing was on laptops. In fact they state, "We also tested some desktop machines, but did not see any bit flips on those". So the problem isn't as grave as it might at first appear. They speculate that ECC RAM blocks the bit flips and this has also been the experience with MemTest86, most (but not all) of the flips are single bit flips, which ECC would correct.
Disclaimer: I'm one of the MemTest86 developers.
Multiprocessing (Score:3)
Multi-threaded programs really do need those cache flushes to implement their interprocessor communications, don't they? It seems to me that they would be the ones most likely to hit this problem.
Re: (Score:2)
I'm not sure. The locked instructions, compare and exchange and mfence ensure cache coherency so in my experience the flushes are not necessary.
Maybe driver code needs the flushes. Driver needs to know data is really in the RAM before hardware with DMA can get it.
Cache flush instructions seem to be a late addition with SSE2.
Re: (Score:3)
Compare-and-exchange and mfence would be doing cache flush all of the way to RAM and global cache line invalidation, wouldn't they? So, they can potentially be used to hammer too.
Re:Multiprocessing (Score:4, Interesting)
Nope, no cache flush for compare and exchange. Modern CPUs use a modified version of the MESI protocol, where each cache line has a state associated with it (modified, exclusive, shared, invalid in MESI, a few more in modern variants). When you do a compare and exchange, you move your copy of the cache line into exclusive state and everyone else's into invalid. Before this, you must have the line in the shared state (where multiple caches can have read-only copies). When another core wants access to the memory, it will request the line in shared state. If another cache has it in its exclusive state, then the exclusive line will be downgraded to shared and a copy of its contents sent to the requesting site.
If atomic operations had to go via main memory then they would be significantly slower than they are and would be a huge bottleneck for multicore systems.
Re: (Score:2)
I suspect that we could persuade those caches to flush to RAM, simply by exhausting the number of possible lines for that address - if the cache is set-associative. Of course modern processors have multiple levels of cache, so that makes it harder.
Re: (Score:2)
Re: (Score:2)
1. On-die caches are SRAM, not DRAM.
2. On-die caches have ECC.
Re:Multiprocessing (Score:4, Interesting)
The main reasons for flushing the cache are:
Re: (Score:2)
What is new in this report is the fact that they manipulated the RAM bit flips to turn them into an exploit.
From the paper;
Left unchecked, disturbance errors can be exploited by a malicious program to breach memory protection and compromise the system. With some engineering effort, we believe we can develop Code 1a into a disturbance attack that injects errors into other programs, crashes the system, or perhaps even hijacks control of the system. We leave such research for the future since the primary objective in this work is to understand and prevent DRAM disturbance errors.
They have demonstrated the bit flip but not the exploit. An exploit would be much more difficult as you would need access to memory right next to the location you need to flip. Then flip it in just the right pattern to not crash. They have done the easy part and left the hard part to someone else.
Re: (Score:2, Interesting)
Similarly, this is a relatively well documented issue in the embedded world as well...
ARM have erratum for half a dozen IP revisions over the past few decades, as do many IHVs that make SoCs based on them.
Similar deals in the MIPS and PowerPC realms.
Some architectures thankfully have a rather locked down MMU/MPU, where unprivileged code simply can't even attempt to rowhammer (some ARMs are like this) - alas, most do not - thus you're at the mercy of all the other hardware vulnerabilities in your system (not
Re: (Score:2)
It's a matter of speed and density too. The vast majority of embedded stuff operates at significantly lower speeds/throughput/memory size requirements, which means there's less vulnerability. Also, embedded stuff tends to be aimed at running very specific applications, which also reduces the vulnerability.
Re: (Score:3)
What is new in this report is the fact that they manipulated the RAM bit flips to turn them into an exploit.
That's bigger than being able to corrupt memory in the first place. What it means is that every computer (laptop I guess, without ECC) is vulnerable to a privilege escalation exploit, and the difference between root and a normal user is meaningless.
:)
Next all we need is a way to exploit this from javascript.
Re: (Score:2)
What about servers that employ data scrambling? From the sound of it, this should completely defeat the Hammer exploit.
http://en.wikipedia.org/wiki/M... [wikipedia.org] /scrambling
Deja vu... (Score:5, Interesting)
This problem is remarkably similar to a problem I encountered in the memory of a 7094 (old
IBM computer) which had a core memory which stored 36-bit words. The memory was supposed
to work by operating on 6 bits at a time at 200 nanosecond intervals. The reason for this was to avoid
creating a magnetic field that was too strong. The problem occurred when the timing was off due
to failure of a component and two of the intervals overlapped. This meant that when one attempted
to store a word with 35 1s, the field created was strong enough to store 36 1s. We wrote a
diagnostic to demo the problem, and with that the engineers were able to isolate and fix the problem
in short order.
Re:Deja vu... (Score:5, Funny)
Alright, alright! We're getting off your lawn!
Re: (Score:2, Offtopic)
words do not mean anything today as each cpu has a different number of bytes representing each word.
How much ram is that?
Re:Deja vu... (Score:5, Interesting)
I was describing something that happened in a machine that was built before the world settled
on 8-bit bytes. The machine had 36-bit words, and each word had an address. The 6-bit
nibbles were not addressable. It was 32,768 (2**15) words of 36 bits. Equivalent
to a little over 100K bytes!
Re: (Score:2)
Wow! That was HUGE for the day! I grew up on PDP-8's which were limited to 4096 12-bit words (unless you used bank selection extensions - some machines had more) and soon migrated to 64K 16-bit words on the PDP-11, but I did my time with IBM's 360 and Control Data's 6xxx series (with its odd 60-bit word), too. Christ on a crutch, how impoverished the world is as far as computer architectures go. And, I'm getting old. Time to go lawn-yell.
Re: (Score:2)
I know, you'd implement ECC by visually inspecting the pins.
Re: (Score:2)
Re: (Score:3)
We wrote a diagnostic to demo the problem, and with that the engineers were able to isolate and fix the problem
in short order.
That claim alone is enough to date your story back at least 30 years.
Re: (Score:3)
Re: (Score:2)
Just hedging my bets :)
Difficult to exploit on servers (Score:5, Informative)
In reality this would be difficult to exploit on a server since servers typically use ECC memory. ECC memory can typically detect two bits and correct one bit error and will likely catch this unless you can flip enough bits correctly so that the ECC remains correct. Doing this means that you would need to know the contents of those memory locations prior to flipping the bits.
I don't know about X86, but on the CPUs my company makes we support hardware address randomization, so that the address lines going out to memory are randomized such that finding adjacent rows or columns can be very difficult to figure out.
It's a shame that Intel only supports ECC memory with their XEON processors rather than all of their processors. ECC does not add much in terms of cost, only 12.5% more DRAM chips and a few more traces and a few other miscellaneous parts (resistors, capacitors). Even the lowest end processors my company makes (for things like small routers, wireless access points, etc) supports ECC and address line randomization.
Re: (Score:2)
http://ark.intel.com/products/77480/Intel-Core-i3-4130-Processor-3M-Cache-3_40-GHz
I picked the first ARK link & the i3 supports ECC RAM.
.
Re: (Score:2)
The problem is you don't know how many bits have flipped, and if only one bit has flipped it will get corrected when you check. If two bits flip then it will also be detected and the fact that this occurring will be reported. Depending on the OS, it will either kill the application and lock out that block of memory or it will cause the system to halt. In any event, one and two bit errors will be reported and detected.
Re: (Score:2)
Flipping more than one bit with ECC is far more difficult since you need to make sure that there is no read operation involved before the write operation. You also need to make sure that the server isn't doing memory scrubbing. If memory scrubbing is taking place, which is something I would expect any decent server to do, it will detect and correct a single bit error long before three bit errors are generated. Also, if you don't generate three bit errors but only one or two or more than three then it will b
old servers as desktops (Score:2)
So I'm not (quite) a paranoid nutcase for running server-class hardware, including always using ECC DIMMS. Current desktops are older Dell T3500s, with nearly top bin Xeons, upgraded supplies and graphics, plus, of course, 24GBytes of ECC RAM.
First big splurge on a desktop had a Tyan mainboard with the ServerWorks chipset (since Intel's were pathetic, at the time), dual P-IIIs, PCI-X, PLUS an AGP slot. Awesome, for its time.
http://www.tyan.com/archive/l_chinese/html/pr01_s2567.html [tyan.com]
Thanks to Wang (Score:5, Informative)
Re: Thanks to Wang (Score:5, Funny)
Re: (Score:2)
Calling their global support service Wang Care wasn't a great move.
(the story goes that the European head had to answer directly to Dr. Wang about why the name had been changed from Wang Care to whatever it ended up being)
Opening an office in Cologne, Germany wasn't a successful one either - no one wanted to go to Wang Cologne ;-)
Re: (Score:2)
Re: (Score:2)
Because it was using parity ... in a computer!
Though surely those patents have expired by now. Time for parity ram to make a comeback?
[citation needed] (Score:2, Interesting)
I've followed the PC market since the 1970s. I was paying a good bit of attention to memory cost. As far as I could tell, people noticed that parity RAM hardly ever caught errors, and that non-parity RAM was cheaper than parity RAM. Parity became optional, then eventually went away entirely, simple because it was marginally more expensive.
Patent issues came and went, but I don't think they were a major driver away from parity.
Re: (Score:2)
The Wang patent was actually for having nine chips on a SIMM. When Wang started enforcing its patent, competitors switched to putting three chips on a SIMM instead. During that transition, parity RAM was scarce and expensive -- 9-chip because it was being phased out and 3-chip because quantities weren't available at first. It got people to reconsider whether parity was necessary, and it became "socially acceptable" to have non-parity RAM.
Back in the days of discrete RAM chips [altervista.org], they were always installed in
Re: Thanks to Wang (Score:4, Informative)
Not so.
Many had ECC. AAPL computers skipped ECC, to save money and look stupid at the same time (I made the stupid part up).
AAPL = Apple Inc., FYI
Re: (Score:2)
Escalation (Score:2)
Re: (Score:2)
Why? Because you cannot make code run in different sections. Here, the physical hardware is PROVIDING the facility to access a table which is normally privileged, which determines whether a program is allowed to access ANY AND ALL RAM.
The privilege is not normally available, and would normally block almost all such attacks. This is a complete way around all the hardware features that are supposed to stop this kind of access and so, of course, the kernel can do NOTHING about it.
The problem is that most so
Re: (Score:3)
I wonder if there is -any- way to mitigate this in software, similar to how the Linux kernel intercepted the instructions to prevent the FDIV bug from happening in early Pentium chips. The only way I see would be to use a Bochs style emulator, and deal with its immense performance hit that its style of emulation does (where hardware virtualization hooks are not used.)
Re: (Score:2)
Of course there is. The question is how quickly it could be implemented, and what type of performance overhead it would take, and if it is worthwhile.
Re: (Score:2)
Re: (Score:2)
Easier said than done in a lot of cases. For example, if a newer Macbook has this bug, the only way to fix the problem is to toss the entire thing.
Having some form of software remedy, even if it is something that might see it happening and do a hard reset or a power down, may be better than a compromise in come environments, especially with regards to virtualization where getting ring 0 on the bare metal can be an incredible catastrophe.
Re:Frist Psot!! (Score:5, Funny)
I got First Post!!!!!!! Yippppppeeeeeeee!!!!!!!!
And I don't even know what a DRAM rowhammer is!!!!!!!!!!
Dude, guess what? We row-hammered you into second place. Now excuse me while I flip you the bit. :-)