Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Hardware

DDR4 Memory Protections Are Broken Wide Open By New Rowhammer Technique (arstechnica.com) 115

"An unprivileged application can corrupt data in memory by accessing 'hammering' rows of DDR4 memory in certain patterns millions of times a second, giving those untrusted applications nearly unfettered system privileges," writes long-time Slashdot reader shoor. Ars Technica reports: Rowhammer attacks work by accessing -- or hammering -- physical rows inside vulnerable chips millions of times per second in ways that cause bits in neighboring rows to flip, meaning 1s turn to 0s and vice versa. Researchers have shown the attacks can be used to give untrusted applications nearly unfettered system privileges, bypass security sandboxes designed to keep malicious code from accessing sensitive operating system resources, and root or infect Android devices, among other things. All previous Rowhammer attacks have hammered rows with uniform patterns, such as single-sided, double-sided, or n-sided. In all three cases, these "aggressor" rows -- meaning those that cause bitflips in nearby "victim" rows -- are accessed the same number of times.

Research published on Monday presented a new Rowhammer technique. It uses non-uniform patterns that access two or more aggressor rows with different frequencies. The result: all 40 of the randomly selected DIMMs in a test pool experienced bitflips, up from 13 out of 42 chips tested in previous work (PDF) from the same researchers. "We found that by creating special memory access patterns we can bypass all mitigations that are deployed inside DRAM," Kaveh Razavi and Patrick Jattke, two of the research authors, wrote in an email. "This increases the number of devices that can potentially be hacked with known attacks to 80 percent, according to our analysis. These issues cannot be patched due to their hardware nature and will remain with us for many years to come."

The non-uniform patterns work against Target Row Refresh. Abbreviated as TRR, the mitigation works differently from vendor to vendor but generally tracks the number of times a row is accessed and recharges neighboring victim rows when there are signs of abuse. The neutering of this defense puts further pressure on chipmakers to mitigate a class of attacks that many people thought more recent types of memory chips were resistant to. In Monday's paper, the researchers wrote: "Proprietary, undocumented in-DRAM TRR is currently the only mitigation that stands between Rowhammer and attackers exploiting it in various scenarios such as browsers, mobile phones, the cloud, and even over the network. In this paper, we show how deviations from known uniform Rowhammer access patterns allow attackers to flip bits on all 40 recently-acquired DDR4 DIMMs, 2.6x more than the state of the art. The effectiveness of these new non-uniform patterns in bypassing TRR highlights the need for a more principled approach to address Rowhammer."
While PCs, laptops, and mobile phones are most affected by the new findings, the report notes that cloud services like AWS and Azure "remain largely safe from Rowhammer because they use higher-end chips that include a defense known as ECC, short for Error Correcting Code."

"Concluding, our work confirms that the DRAM vendors' claims about Rowhammer protections are false and lure you into a false sense of security," the researchers wrote. "All currently deployed mitigations are insufficient to fully protect against Rowhammer. Our novel patterns show that attackers can more easily exploit systems than previously assumed."
This discussion has been archived. No new comments can be posted.

DDR4 Memory Protections Are Broken Wide Open By New Rowhammer Technique

Comments Filter:
  • by crow ( 16139 ) on Monday November 15, 2021 @07:54PM (#61991919) Homepage Journal

    If you have hardware encryption on your DRAM, it would seem to make it much harder for these attacks to work. I suppose if you only need to flip a bit, you could still do that with a few tries, but it would be randomly flipping bits in whatever the encryption word size is.

    • Re:Encrypted Memory (Score:5, Informative)

      by NFN_NLN ( 633283 ) on Monday November 15, 2021 @08:59PM (#61992045)

      ECC is much more common and seems to mitigate the issue. They probably should have lead with this:

      "While PCs, laptops, and mobile phones are most affected by the new findings, the report notes that cloud services like AWS and Azure "remain largely safe from Rowhammer because they use higher-end chips that include a defense known as ECC, short for Error Correcting Code."

      • by brunes69 ( 86786 ) <slashdot@keirsGI ... minus herbivore> on Tuesday November 16, 2021 @04:52AM (#61992705)

        Indeed. ECC is needed for any business critical workload in any context, simply to protect against the random bit flips that happen due to natural background radiation.

        • For the small number of systems that run rad-hard code, this stuff also has no effect. It's kinda neat that once you've engineered a system that can handle dozens of SEUs (radiation-induced faults) every day, anything else just bounces off. You can this either with 1oo1D code that detects faults and quickly restarts ("rejuvenation"), or TMR (triple modular redundant) variable storage that corrects any bit-flip errors.
    • Re: Encrypted Memory (Score:4, Interesting)

      by Z00L00K ( 682162 ) on Monday November 15, 2021 @10:29PM (#61992241) Homepage Journal

      And if the intent is just to create a blue screen of death or similar then encryption is useless. Encrtption also restricts performance.

      The first step should be to implement ecc on all memory modules. Then consider further options as well since I suspect that ecc also can be targeted with a modification of this attack.

    • If you have hardware encryption on your DRAM, it would seem to make it much harder for these attacks to work. I suppose if you only need to flip a bit, you could still do that with a few tries, but it would be randomly flipping bits in whatever the encryption word size is.

      This is what I don't quite understand. Have always been under the impression memory controllers jumble addressing as a matter of course. On even quite old systems there are switches in BIOS settings for things like "memory scramblers" that randomize access to prevent noise associated with sequential hits.

      Is this an exception? Do few systems do this? Do the attacks bypass the scramblers in some way?

      Likewise I've wondered what the point of the pattern checks in memtest86 are if this is commonly used.

    • Re:Encrypted Memory (Score:4, Informative)

      by Hentes ( 2461350 ) on Tuesday November 16, 2021 @02:16PM (#61993889)

      Randomly flipping bits is literally all that rowhammer does. It's not a surgical strike, more like monkeys on a typewriter. The rowhammer based proof of concepts that I've seen basically just targeted the memory that a privileged process runs in, hoping that one of the flips they introduce will be the address of a jump, and the bitflipped address will point to an area of memory they control. This kinda worked with 32bit systems where usually every address was valid, but even there a successful attack took about 5-10 hours and was anything but subtle. But 32bit systems were already being phased out by the time rowhammer was discovered, and on 64bit systems you have a much bigger chance of just crashing whatever you are hammering instead of hijacking it. Which is why rowhammer has remained, and probably will remain a purely academic attack,

  • New job for Mozilla. :)

    • Maybe not everywhere, but the Dell PowerEdge T110 I have here at home has 32GB of ECC RAM, so I guess I'll keep it around. :-) The home-built ASRock Z77 E3 / i7-3770 system also has 32GB RAM but it doesn't support ECC. The (even) older Dell XPS 420 and Dell Inspiron 530 systems only have 8GB non-ECC RAM ... The first two systems run Linux, the latter two run Windows 10 (just fine btw). (I inherited some/all of the parts or systems from friends who were upgrading their systems and I filled them out...)

  • by ctilsie242 ( 4841247 ) on Monday November 15, 2021 @08:07PM (#61991957)

    For any long computations, ECC RAM is a must. Why have not we moved to ECC RAM across the board, and not just server CPUs? It not just would render these attacks useless, but also provide more reliable computing day to day.

    Done right, ECC RAM, plus CPU level encryption can mitigate almost all attacks via this vector.

    • by caseih ( 160668 ) on Monday November 15, 2021 @08:15PM (#61991967)

      Intel gets complete blame for this. They are trying to make more money by dividing the market up and making ECC a "premium" feature. Shame on them. Maybe this pretty thorough, devastating, attack will bring them to their senses.

      • Comment removed based on user account deletion
      • Intel gets complete blame for this.

        They sell what people will buy, if people stop buying non-ECC computers then Intel will stop making them.

        To get people to stop buying them means this kind of attack gets the kind of attention that the "ILOVEYOU" worm got, which is unlikely. Intel makes what people will buy and if people will buy non-ECC systems because they are cheaper than ECC systems then Intel will keep making them.

        People work to make money so why denigrate Intel for making money? Do you work to make money? I would guess that you do.

      • Intel gets complete blame for this. They are trying to make more money by dividing the market up and making ECC a "premium" feature. Shame on them. Maybe this pretty thorough, devastating, attack will bring them to their senses.

        It is a premium feature. ECC is not a security feature, you're trying to pretend it is because of some crazy hypothetical attack. There's no sense in using memory with error correction and detection capabilities on a board and processor that don't have similar reliability features. It's like using shielded gold-plated audio cables with POS speakers and receiver.

    • ECC Ram uses extra bits to keep everything in check.
      So the size of the chip is slightly larger which results in a higher price.

      • ECC Ram uses extra bits to keep everything in check. So the size of the chip is slightly larger which results in a higher price.

        The registered/buffered versions also have more circuitry.

      • by NFN_NLN ( 633283 )

        Slashdot noobs. Don't you memorize slashdot articles. It was only 11 months ago we had an entire expose on this bro!

        https://linux.slashdot.org/sto... [slashdot.org]

      • > So the size of the chip is slightly larger which results in a higher price.

        Yeah, but maybe 20% more logic, max, and prices can be 3x due to basically a captive market and price collusion among manufacturers.

        I'd gladly pay 20% more for ECC everywhere and only buy AMD bioses that get it right (so many are buggy with ECC).

        Intel can pound silicon with its Xeon-only nonsense.

      • So the size of the chip is slightly larger which results in a higher price.

        In my experience, ECC memory sticks normally have extra memory chip(s) instead of larger ones, often 9 instead of 8 (or 18 instead of 16 for doublesided sticks).

      • by AmiMoJo ( 196126 )

        DDR5 is going to be ECC only, kinda.

        All DD5 chips will have internal ECC, necessary due to the extremely high densities and susceptibility to things like cosmic rays. The smaller the memory cells get and the lower the voltage they use, the less energy is needed to flip a bit.

        RAM will still be sold as ECC and non-ECC though, with the difference being if the computer can see the ECC bits or not. There will probably be some extra circuitry involved too, and doubtless higher costs.

    • by Gravis Zero ( 934156 ) on Monday November 15, 2021 @08:20PM (#61991981)

      For any long computations, ECC RAM is a must. Why have not we moved to ECC RAM across the board, and not just server CPUs? It not just would render these attacks useless, but also provide more reliable computing day to day.

      Mostly because of Intel. No seriously, they REFUSE to support ECC RAM in anything that isn't a server. As for AMD, all Ryzen chips support ECC memory... but not all AM4 motherboards do.

      • One wonders if Intel has funded this article. Note how the headline is "DDR4" Because DDR5 has ECC built in ... and Intel is first with DDR5 support.

        • One wonders if Intel has funded this article.

          Only if one isn't very smart.

          Note how the headline is "DDR4" Because DDR5 has ECC built in

          The headline is DDR4, because DDR4 has a different RH mitigation strategy than DDR5 (TRR vs RFM) and no one has figured out how to do this against RFM yet.
          And no, DDR5 does not have "ECC built in"

          and Intel is first with DDR5 support.

          So, an exploit is found for an older, but still dominant, technology. Therefor, because reasons, the early adopters of the new technology are "behind" any articles that bring up security flaws in the older tech?

          Time to take your thorazine.

          • by evanh ( 627108 )

            Wow, LOL, quite the over-reaction. ECC isn't intended as a mitigation, so really just marketing.

      • Mostly because of Intel.

        Eyeroll.

        More likely, because of the free market.
        Non-ECC RAM is cheaper. That's a fact. It's not cheaper because of Intel. It's cheaper because there are less DRAM cells.
        As long as such a thing can be had for cheaper, there will be a market for it.

        • If your thesis about free markets were true, then ECC RAM would only cost about 12% more than normal RAM, and probably most people would buy it. I sure would.

          But that's not how real markets work, largely because most of them aren't even approximately "free".

          • If your thesis about free markets were true, then ECC RAM would only cost about 12% more than normal RAM, and probably most people would buy it. I sure would.

            Utterly incorrect. You do not understand a free market.
            You do not represent total supply and demand in a sector.

            But that's not how real markets work, largely because most of them aren't even approximately "free".

            You're right, that laughable caricature you gave isn't how free markets work.
            But not because they aren't free, because you don't know what you're talking about.

            Feel free to demonstrate how the market on ECC vs. Non-ECC RAM is not free.
            Avoid the handwaving and specious claims this time.

            • You can count all of the major CPU vendors on one hand, mostly because they form a cabal of patent cross licenses. With such a small set of actors, this oligopoly can effectively collude to *not* offer affordable systems that support ECC.

              This particular market is so NOT free, it's laughable that you would even bring up that word when talking about it.

              • You can count all of the major CPU vendors on one hand, mostly because they form a cabal of patent cross licenses. With such a small set of actors, this oligopoly can effectively collude to *not* offer affordable systems that support ECC.

                That would be illegal, and there's no evidence that happens. Furthermore, such is an example of the non-freedom of the CPU market, not the RAM market.
                Again, support for ECC isn't the problem. It's support for non-ECC.
                As long as CPUs support non-ECC RAM, there will be a market for it, period.
                There will always be a market for the cheaper parts.

                This particular market is so NOT free, it's laughable that you would even bring up that word when talking about it.

                More handwavy claims.
                I eagerly await your evidence of collusion in market segmentation, or evidence that market segmentation is unnatural.
                Quit blaming this on CPU

                • Without CPUs, RAM is useless. There is no DRAM market independent of the systems they go into.

                  The CPU vendors have a stranglehold on those systems. This is not illegal, in fact it is encouraged by government patent policies.

                  Bottom line: You can't have a free market if the goods being sold are useless without the blessing of a cabal. I'm sure the DRAM vendors don't mind the artificial opportunity given to them by CPU vendors to sell the 12% more complex parts at ridiculous extra margins, either.

                • https://en.m.wikipedia.org/wik... [wikipedia.org]

                  That isn't specific to ECC RAM, but it should at least demonstrate that there is a DRAM cartel. JEDEC is pretty notorious.

                  DRAM resellers know that the only market for ECC is server/workstation so they charge what the market will bear. Or more like what it can be made to bear. But if those who produce DRAM controllers required ECC then market pressure would push ECC DRAM prices downward.

                  Conveniently, only a few companies like AMD make it (relatively) easy to use ECC RAM on

                  • That isn't specific to ECC RAM, but it should at least demonstrate that there is a DRAM cartel. JEDEC is pretty notorious.

                    JEDEC is not a cartel.
                    JEDEC is a standards organization that includes nearly every computing entity in the world.
                    Price-fixing has indeed occurred. And was prosecuted.

                    DRAM resellers know that the only market for ECC is server/workstation so they charge what the market will bear. Or more like what it can be made to bear. But if those who produce DRAM controllers required ECC then market pressure would push ECC DRAM prices downward.

                    Correct. They charge what the market will bear.
                    Yes, if those who made DRAM controllers required ECC, then that would push it.
                    So, as I said, the problem is the support for non-ECC, not the lack of support for ECC.
                    As long as AMD and Intel both support non-ECC RAM, it will continue to be made.
                    It will continue to be prominent deployed technol

                    • The only way a transition to ECC-only could be forced is by the dropping of support for non-ECC RAM.

                      People make what people will buy, Intel is bound by this rule as much as anyone. People buy non-ECC RAM because it is lower cost than ECC RAM. To force the transition to ECC only would mean people predominately buy only ECC systems. One way to get people to buy ECC only systems is to have some security issue make the 5:00 news that affects only non-ECC systems. Given the many protections against such attacks already, such as pseudo-random refresh of RAM, this is not likely.

                      The more likely way to get ECC

                    • LOL

                      You honestly think the price fixing stopped? We're done here.

                    • People make what people will buy, Intel is bound by this rule as much as anyone.

                      That was my point, precisely.

                      One way to get people to buy ECC only systems is to have some security issue make the 5:00 news that affects only non-ECC systems

                      Right. Because that has ever worked ever, in the history of ever.
                      Remember, for the stated purpose above of "Making all RAM ECC", one would have to make people unwilling to buy non-ECC DRAM. You'd have to make the market for it small enough to be worth abandoning.

                      The more likely way to get ECC only is to see RAM prices get low enough that the price differential between ECC and not ECC is so small that offering ECC and non-ECC options costs more than just offering ECC only. I suspect we are quite close to seeing ECC only be the norm as it is.

                      You're going to have to define "quite close", because I don't see it at all.
                      There isn't an incentive to move to it, therefor there is money to be saved. There will always be money to be saved, because it requires 11% m

                    • Oh, fucking spare me. Any shit-for-brains can weave conspiracy tales.
                  • "Also OEMs hate anything that increases BoM so they would resist changes to existing norms."

                    They don't seem to resist too well selling laptops with discrete graphic cards...
                    Or with high-resolution displays (retina)...
                    Or with high intensity backlight displays (500+ nits compared to the usual 300-350)...
                    Or with internal expansion space...
                    Or with brushed Aluminum enclosures...
                    Or with this, or with that.

                    A relatively inexpensive ECC option (maybe 5% of total device price, or some 20% on memory and processor toge

                    • A relatively inexpensive ECC option (maybe 5% of total device price, or some 20% on memory and processor together) would be welcomed on "engineering" laptops, on (probably) "software development" laptops, on "financial" laptops.

                      It's doable today (at least on AMD machines)
                      Due to the lack of that, I suspect how welcome it is to you doesn't represent what they perceive as the market.
                      Or perhaps the makers of AMD laptops are also in cahoots with Intel to stifle the adoption of ECC RAM as the dumbfuck AMD fuckboys on this thread would have you believe.

                      It doesn't help that ECC RAM does significantly alter the thermal and power characteristics of the device.
                      At the end of the day, you're refreshing 12% more memory cells, and validatin

                    • "Or perhaps the makers of AMD laptops are also in cahoots with Intel to stifle the adoption of ECC RAM as the dumbfuck AMD fuckboys on this thread would have you believe."
                      Going by historic precedent, Intel cried left, right and center that the future of 64 bit computing is Itanium. At least until they get their own 64bit x86 processors.
                      Not to mention other sketchy moves (like in providing funds for marketing for the first ultrabooks but only to companies that didn't sell AMD laptops).
                      Intel has a rich histor

                    • As for the memory errors... you can encounter any number of memory error in unused memory and don't care. And there are used memory areas where in many cases you don't care for memory errors too - mp3 files and movies can have lots of errors in _some_ areas without a significant result.

                      Na. Part of ECC is the reporting of errors.
                      I've managed hundreds of servers- all with ECC- for over a decade and a half now.
                      You will never run into a single-bit error in your life, and in the case of a failing module, your system is going to crash before the machine check exception happens anyway.

            • Comment removed based on user account deletion
              • Markets are legal frameworks created by and controlled by governments. You speak as if they are sentient beings.

                I do no such thing. That's 100% in your own head.
                A "market" is a roughly defined entity that conforms to a set of stochastic rules.
                If you are unable to understand how such things can be generalized, I bet population statistics must confuse the fuck out of you.

                For what it's worth, I'd expect no better from a BSD user ;)

      • Most workstations have ECC ram. My aging Lenovo box is maxed out with 24gb of ECC.

      • Why should it matter, what Intel supports?

        ECC RAM could and should be entirely self-contained within the memory chip. It should clean up its data before handing it out. As an optional feature - not requiring external support - it could provide information on when/where errors are corrected. However, if the chipset doesn't want that info, the ECC should work anyway.

        • by swilver ( 617741 )

          It doesn't work that way. ECC RAM is just normal RAM with another chip. The CPU and Chipset use this extra chip to store the error correction information, and interpret it and scan for ECC errors every now and then (frequency settable in BIOS).

          I agree with you though that it be much nicer if RAM could just present itself as standard 8 chip and do the ECC on its own.

        • You sound like the clueless corporate middle manager stereotype.

      • by Sloppy ( 14984 )

        they REFUSE to support ECC RAM in anything that isn't a server.

        This is really a bad way of looking at it. The hardware is what it is, regardless of how you use it. Intel doesn't decide whether or not you use the chip in a server; you do. A Xeon will run a web browser or video games just fine. (Of course, so do all of AMD's chips...)

        • This is really a bad way of looking at it.

          This is the only way a rational and informed person could look at it because Intel used ECC RAM exploitative as a selling point for using their exceptionally expensive server chips instead of their desktop chips. Intel made it very clear that the only way you could use ECC RAM was if you paid them $$$ and while playing up how unreliable RAM was. It was all about money and how they never wanted you to have to option of paying them less.

    • Why have not we moved to ECC RAM across the board, and not just server CPUs?

      I believe you answered your own question in the next sentence.

      It not just would render these attacks useless, but also provide more reliable computing day to day.

      There's plenty of people that will buy the lower priced option over the more reliable option. Computers are very reliable as they are, if this was an issue then non-ECC memory would not even be an option.

      Done right, ECC RAM, plus CPU level encryption can mitigate almost all attacks via this vector.

      Don't recent versions of Windows and macOS already use some kind of memory scrambling to mitigate against these attacks? I thought I read that somewhere. People concerned about these kinds of attacks should be well protected with ECC, malware

    • by DamnOregonian ( 963763 ) on Monday November 15, 2021 @09:18PM (#61992097)

      Done right, ECC RAM, plus CPU level encryption can mitigate almost all attacks via this vector.

      Encryption alone does the trick pretty well. But only for now.
      ECC has been broken for Row Hammer since 2018. [ieee.org]

      This was always going to be the case, and adding a parity bit was never going to offer anything but an increased-time-to-exploit level of security.

      The Row Hammer mitigation strategy for DDR4 (TRR) is old. Older than DDR4. It's been supplanted by RFM in DDR5. That's the best protection- to continue to mitigate the the inherent vulnerability of DRAM to row hammering.

      Even hardware encryption will eventually be broken by some kind of side channel.

    • DDR5 doesn't have system level ECC but it has die level ECC.

    • ECC RAM is slightly more expensive (as you need to store extra, unusable bits).
      And in the past, the small RAM size made errors less common (a one in 10 billions error will happen 1000 times more often in a 16GB computer than in a 16MB computer.
      Also, I don't know if ECC makes an impact on "memory speed", and many producers sell "premium" "extra speed" memory modules for extra money as "flagship" products.
      So, when the usual consumer can buy DDR-4333 for $120 or DDR-4200ECC for $150, the choice will probably b

    • Why have not we moved to ECC RAM across the board

      Same reason the Spectre mitigations rolled out in the Linux kernel were Opt-in and disabled by default: Performance. *You* may have a requirement for ECC RAM. My gaming PC does not. No one will really be affected if my ./ post ends up with some bits flipped or a character misplaced. Likewise the complexity attack (detailed knowledge of the target system) renders it moot for all but the most targeted and well funded attackers.

      We don't use ECC in general purpose PCs for the same reason we live in houses with

    • by fazig ( 2909523 )
      For the same reason you don't use Special and General Relativity to teach kids how the arc of a thrown ball comes to be:
      Too much overhead spent on getting it as accurate and precise as possible, where a bit of error, from Newtonian Mechanics, is still close enough to do the job in the vast majority of cases and most importantly is a lot faster.

      Most of our day to day computer usage doesn't need extremely high precision and error corrections to keep error propagation low, hence approximations are often good
      • Most of our day to day computer usage doesn't need extremely high precision and error corrections to keep error propagation low, hence approximations are often good enough.

        The problem with this statement is bit errors are unrelated to precision. They could crash your program or your computer or corrupt any (non)persistent data. They can induce an unlimited number of defects with unknowable consequences. Lack of precision in a calculation can be understood and quantified. This is not possible with ram. The analogy to low velocity limits is an applies to oranges comparison that are not at all equivalent.

        If I had a nickel for every time I've heard some self-proclaimed nerd complaining about lack of ECC support, potential Meltdown and Spectre issues, justifying their hardware purchases and then seeing how their use cases take absolutely no advantage of any of those protections...

        Shitty ram (Which passed multiple 24+ hour burnin tests) personally co

        • by fazig ( 2909523 )
          That's what it usually comes down to from my own experiences with bit errors.
          It's the most likely explanation when some of your numbers runs awry, while it shouldn't. Then sure, it might have been the odd bit that was flipped by some cosmic background radiation.

          Of course you're correct that there's plenty of other stuff in the memory which can be affected by flipped bits.
          However in the case of crashes and data corruption, there's so many possible causes that it becomes nigh impossible to isolate the caus
          • Of course you're correct that there's plenty of other stuff in the memory which can be affected by flipped bits.

            However in the case of crashes and data corruption, there's so many possible causes that it becomes nigh impossible to isolate the cause to a bit error in the RAM unless it's seriously flawed RAM that's way substandard for even non ECC or is an user error like overclocking the memory too aggressively.

            After my memory problems I did some digging and discovered a number of memory integrators scrape low grade chips from the bottom of the bin and don't even have the necessary equipment to properly test integrated memory sticks. One vendor for a time was actually passing chips with non-zero detectable errors. I guess they figured if it works for displays hell why not RAM?

            I now only buy memory from producers of the chips themselves Samsung, Micron, et el.

            However in the case of crashes and data corruption, there's so many possible causes that it becomes nigh impossible to isolate the

            In my case its fairly definitive. I don't do overcloc

            • by fazig ( 2909523 )
              Then you'd be a fringe user.
              Even with a selection bias due to the fact that we're on Slashdot here, it's difficult to believe that all the outrage you read from users to be justified and not people who just like to complain about random shit, when it comes to things like this on consumer electronics.

              Anyway, for most people those things are simply not relevant, which would be the main reason why you don't find ECC as the standard in consumer electronics.
              Consumers, if they even know what they want let al
              • Then you'd be a fringe user.
                Even with a selection bias due to the fact that we're on Slashdot here, it's difficult to believe that all the outrage you read from users to be justified and not people who just like to complain about random shit, when it comes to things like this on consumer electronics.

                I only explained my personal experience and unwillingness to waste any further time dealing with aftermath of unexplained OS and software crashes data corruption and debugging memory issues. Feel free to label me however you please.

                Also as far as SPD goes, in some cases it's the mobo that have shitty support. I've had some decent kits from G.Skill and Corsair that would POST on ASUS and MSI boards, but not on Gigabyte for example. You can't even trust those QVLs in these times to not be rushed out.

                Very much doubt there is such a thing as decent kits from integrators like G.Skill and Corsair. I certainly am unwilling to waste any further time and money to find out.

                If the clocks are fine then usually the timings are quite loose. And while they're often great overclockers, because they usually are from decent bins, putting the work into overclocking them is a huge pain in the ass, like already mentioned.

                Personally have less than zero interest in overclocking.

                • by fazig ( 2909523 )
                  It's not meant to be offensive in any way. It's not meant to invalidate your use case.
                  If those are your criteria you're simply not within the vast majority of use cases. And that's fine.

                  It just means that doing what you do isn't something that's required to be done "across the board" by any stretch. That's what my point is all about.

                  Personally I've used G.Skill and Corsair kits a lot. I usually pick the 3200MT CL14 or 3600MT CL16 kits. The required information can be obtained from computer hardware for
    • by kackle ( 910159 )

      Why have not we moved to ECC RAM across the board, and not just server CPUs?

      I built an ECC machine a long time ago. Isn't it slightly slower, more expensive and uses 12% more power for the RAM?

    • intel solved this *decades* ago,

      check out the spec sheet on the 1101A:

      https://drive.google.com/file/... [google.com]

      only needs two power levels, and with a couple of gigs of these, your server will keep ice off the roads for the entire city!

      Just *try* and flip a bit with these . . .

    • For any long computations, ECC RAM is a must. Why have not we moved to ECC RAM across the board, and not just server CPUs? It not just would render these attacks useless, but also provide more reliable computing day to day.

      Done right, ECC RAM, plus CPU level encryption can mitigate almost all attacks via this vector.

      "Server CPUs", like Xeons, have error detection and/or correction features that complement ECC. They go together, so what's the point in only having one or the other? What are you trying to accomplish by using RAM with parity, but then internal CPU cache, busses, interconnects etc. without equivalent parity or error correction? Why? Specifically because of hypothetical rowhammer attacks? If Intel wanted to support consumer usage of ECC they have to upgrade consumer CPUs to at least some minimum level o

    • by stikves ( 127823 )

      Yes Intel is to blame. But also it won't have wider acceptance, since it is slow:
      https://www.reddit.com/r/Amd/c... [reddit.com]

      I have looked for faster ECC RAM, but manufacturers stay in spec for stability. With non-ECC RAM it is possible to get almost 100% overclocked ones on the market, with no issues, except for needing a huge heatsink.

      If the market only gives 2666 in ECC, 5333 in non-ECC, it would be a tough sell (not to mention, they are also more expensive atm).

  • by gweihir ( 88907 ) on Monday November 15, 2021 @09:37PM (#61992139)

    In normal PCs, that is. I failed on several systems to get any effect. I do not know anybody that got an effect on a regular PC. All published papers I found did this on laptops. Laptops reduce memory refresh because that saves a significant amount of power. And a slower refresh makes memory vulnerable to Rowhammer.

    So, has anybody been able to reproduce this on a real PC with regular DRAM refresh? I would like to know, because the idea of Rowhammer is plausible for PCs as well.

    • Re: (Score:3, Informative)

      by gwdoiron ( 1590237 )
      Same here. Any correctly designed memory controller will periodically tell the DRAMs to run an autorefresh cycle, which effectively recharges the capacitance in each row of memory. If laptops are cutting back on the DRAM refresh rates/voltages AND also allowing full speed memory access (thus violating RAM specs), Rowhammer is the least of your problems - you need a new laptop.
  • Security would be slow mo command and control. Stop putting it on atomic level circuitry and use something closer to a tic tac toe board size than a gigapixel picture of Anya Taylor Joy. Then the other circuits are too far to affect bits nearby, which would be across the Grand Canyon using ancient circuit size.

  • What exactly am I supposed to do with this information? Okay, it's a curiousity.

    • We are supposed to chuckle at the chicken little type of warnings this group puts out on an annual basis. In the real world this is just not a problem (until it is).

      Posts above say that this is only working on laptops because they reduce the DRAM refresh rate to conserve power, possibly more than the DRAM specs allow. And who is running a multi-user server from a laptop?

      -It's the what-if game, and slashdot always falls for it.
  • by diffract ( 7165501 ) on Tuesday November 16, 2021 @04:47AM (#61992697)
    seems fishy
  • by Lady Galadriel ( 4942909 ) on Tuesday November 16, 2021 @07:29AM (#61992889)
    Is it time for the kernels to checksum R/O segments of memory?

    Similar to the way BTRFS, ZFS, HAMMER1/2, (appropriately named for this topic :-), use checksums on file system blocks. As a program is loaded into memory, any code or R/O data segments would have a checksum calculated and put in special memory table. Plus, any data file loaded that was defined as R/O could be likewise protected by memory checksums.

    Unlike checksumming file systems, the checksum would not be checked on access. ECC and encryption would help with access. The main check method would be periodic scanning, (kicked off by cron?), of checksum protected memory. And if a fault is found, freeze access to that MMU page(s). If possible, the source would still be known, and could be re-read off storage. Naturally the error would also be written to a log file, as well as it's out come, (recoverable, unrecoverable). For long running servers, (weeks or months of uptime), this could be quite valuable to detect memory errors in segments that have not been read in a while.

    Of course, this does not help R/W memory. So ECC & Encryption of memory are still quite valuable.

    About 2 years ago I started a writing a paper on this subject, checksumming R/O memory segments. Plus, putting forth a case for improving ELF files with checksums. Perhaps it's time to work on it again, and get the paper published.


    Last summer researching laptops, I found nothing under $1,500 US that seemed to support ECC memory. But, since I was already preferring AMD due to Intel's response to the Meltdown / Spectre problems, I got a laptop with Ryzen Pro CPU. The Pro versions apparently support memory encryption, (the vendor tried to make that a "business" feature...). I enabled it in Linux, but have not yet bothered to see if it's actually working.

"Show me a good loser, and I'll show you a loser." -- Vince Lombardi, football coach

Working...