6 ms·

> My understanding is it's not a complete mitigation but does make exploitation harder. It won't. It's designed to counter silicon limitations to increased de

> My understanding is it's not a complete mitigation but does make exploitation harder. It won't. It's designed to counter silicon limitations to increased density, i.e. it's made to correct the errors that result from packing cells beyond the limit of error-free operation. The extra redundancy from on-chip ECC is intended to be "consumed" by the chip itself, and since this will allow optimizing chip manufacture to denser and cheaper, it's no question at all that it will get pushed to the very limit. There's still "classic" ECC for DDR5. 8 bits mapped to 9, terminated at the CPU which can look at things. That's what I want, need, and will buy. P.S.: Shame on Intel for still walling off desktop CPUs from ECC. https://ark.intel.com/content/www/us/en/ark/search/featurefilter.html?productType=873&0_StatusCodeText1=3,4&0_ECCMemory=True&2_MarketSegment=Desktop https://ark.intel.com/content/www/us/en/ark/search/featurefi...

Dylan16807 5y ago
> It won't. It's designed to counter silicon limitations to increased density, i.e. it's made to correct the errors that result from packing cells beyond the limit of error-free operation. I'd love to see actual parameters for the error correction codes, but DDR5 could pretty easily be a lot more robust than DDR4. When you have no error correction at all, you need ridiculously high reliability. Even if these new memory cells are have a much higher error rate, if they're designed to seamlessly handle a few bits in the same row flipping then the overall reliability could skyrocket. Edit: Oh, there's a paper from micron talking about DDR5 only having single bit correction internally. That's not as useful as it could be against attacks... > There's still "classic" ECC for DDR5. 8 bits mapped to 9 But Single Error Correction, Dual Error Detection is not enough to prevent attacks. Also because DDR5 uses a smaller width you actually need to map 8 bits to 10.
- eqvinox 5y ago
  > I'd love to see actual parameters for the error correction codes Well, the spec is $369, but a PDF with some early discussion (rev 0.1…) says: DDR5 devices will implement internal Single Error Correction (SEC) ECC to improve the data integrity within the DRAM. The DRAM will use 128 data bits to compute the ECC code of 8 ECC Check Bits. However, I have no idea whether this is what got specified in the end. 8 ECC bits on 128 data bits would be half the amount of added redundancy compared to "classical" ECC. Note also it's not SECDED, just SEC, confirming the Micron paper you mentioned. > But Single Error Correction, Dual Error Detection is not enough to prevent attacks. The OP suggested monitoring for a sudden increase in ECC events, which hopefully this would work for. It's not a perfect countermeasure, just a statistical one, but I'll take what I can get... > Also because DDR5 uses a smaller width you actually need to map 8 bits to 10. Now that kinda makes it better, doesn't it? :)
  - Dylan16807 5y ago
    > Note also it's not SECDED, just SEC, confirming the Micron paper you mentioned. Which is a shame because it would only cost 1 more bit to do SECDED. > Now that kinda makes it better, doesn't it? :) Very slightly, but 32->40 isn't much better than 64->72. SECDED requires 39. I don't know if the 40th bit is used for anything? It would certainly be possible to use the 16 extra bits per burst to add a second layer of SECDED. Or an extra layer of triple error detection, if I'm remembering right. That would be really good against rowhammer.
    - eqvinox 5y ago
      > SECDED requires 39. I don't know if the 40th bit is used for anything? FWIW this is completely up to the CPU. "Classical" ECC is completely transparent to the DIMM, it just remembers and returns what the CPU gave to it. 32 → 40 has already been around for quite some time (particularly when the DDR controller only has 64 data lines but you still want ECC you can sometimes do 32+8 at half performance & max capacity) but I don't see anything beyond SECDED in the datasheets... (looked through some Freescale/NXP PowerPC bits)
      - Dylan16807 5y ago
        > FWIW this is completely up to the CPU. "Classical" ECC is completely transparent to the DIMM, it just remembers and returns what the CPU gave to it. True, but I guess I assumed normal ECC was standardized. Is it? > 32 → 40 has already been around for quite some time (particularly when the DDR controller only has 64 data lines but you still want ECC Is that keeping a burst length of 8 on DDR3/DDR4? One thing to consider is that a full memory transfer plus 16 extra bits is much more useful than a smaller transfer with 8 extra bits. That could easily be a tipping point from "not worth bothering" to "they really should do something here".
        eqvinox 5y ago
        > True, but I guess I assumed normal ECC was standardized. Is it? This is outside my area of expertise, but I believe everyone just does the same thing without it being a standard. (Especially since even CPU vendors frequently just buy a done-and-tested DDR controller design.) > Is that keeping a burst length of 8 on DDR3/DDR4? All the "classical" ECC just uses additional data lines, and I assumed DDR5 would do the same thing. I hadn't checked until a minute ago, but yes, DDR5 (like previous versions) just extends the width of the data bus by the ECC bits.
dogma1138 5y ago
That’s not exactly correct whilst it does there mainly to allow for higher densities and frequencies it’s designed to prevent bit flips from happening on chip. It’s not end to end ECC as in it doesn’t prevent flips that happen on the bus or in CPU cache but it does prevent single bit errors on DRAM.
- eqvinox 5y ago
  > it’s designed to prevent bit flips from happening on chip. Bit flips that are getting more and more common as the RAM cells are getting tinier and tinier, the stored charges ever smaller and smaller, and thus susceptible to flipping…
arcticbull 5y ago
I think on-chip ECC would mitigate this problem just as well as off-chip ECC. Off-chip ECC is meant to catch errors during transmission (i.e. 72 bits transmitted for 64 bit words), not necessarily just the ones that occur internal to the package. I agree it's meant to counter limitations due to increased density, but it should catch this to an extent also as this error is induced on-package right, not during transmission. Or am I mistaken?
- monocasa 5y ago
  I think the point the parent is making is that this ECC is already fixing errors. There's no redundancy because the redundancy is already consumed by the defective cells in the chip. Any additional flips such as through rowhammer have no extra redundancy to fall back on in the general case with DDR5's built-in ECC.
  - arcticbull 5y ago
    Ah i see. I didn’t view the errors as additive. Thanks for the clarification!

Dylan16807 5y ago

> It won't. It's designed to counter silicon limitations to increased density, i.e. it's made to correct the errors that result from packing cells beyond the limit of error-free operation. I'd love to see actual parameters for the error correction codes, but DDR5 could pretty easily be a lot more robust than DDR4. When you have no error correction at all, you need ridiculously high reliability. Even if these new memory cells are have a much higher error rate, if they're designed to seamlessly handle a few bits in the same row flipping then the overall reliability could skyrocket. Edit: Oh, there's a paper from micron talking about DDR5 only having single bit correction internally. That's not as useful as it could be against attacks... > There's still "classic" ECC for DDR5. 8 bits mapped to 9 But Single Error Correction, Dual Error Detection is not enough to prevent attacks. Also because DDR5 uses a smaller width you actually need to map 8 bits to 10.

eqvinox 5y ago
> I'd love to see actual parameters for the error correction codes Well, the spec is $369, but a PDF with some early discussion (rev 0.1…) says: DDR5 devices will implement internal Single Error Correction (SEC) ECC to improve the data integrity within the DRAM. The DRAM will use 128 data bits to compute the ECC code of 8 ECC Check Bits. However, I have no idea whether this is what got specified in the end. 8 ECC bits on 128 data bits would be half the amount of added redundancy compared to "classical" ECC. Note also it's not SECDED, just SEC, confirming the Micron paper you mentioned. > But Single Error Correction, Dual Error Detection is not enough to prevent attacks. The OP suggested monitoring for a sudden increase in ECC events, which hopefully this would work for. It's not a perfect countermeasure, just a statistical one, but I'll take what I can get... > Also because DDR5 uses a smaller width you actually need to map 8 bits to 10. Now that kinda makes it better, doesn't it? :)
- Dylan16807 5y ago
  > Note also it's not SECDED, just SEC, confirming the Micron paper you mentioned. Which is a shame because it would only cost 1 more bit to do SECDED. > Now that kinda makes it better, doesn't it? :) Very slightly, but 32->40 isn't much better than 64->72. SECDED requires 39. I don't know if the 40th bit is used for anything? It would certainly be possible to use the 16 extra bits per burst to add a second layer of SECDED. Or an extra layer of triple error detection, if I'm remembering right. That would be really good against rowhammer.
  - eqvinox 5y ago
    > SECDED requires 39. I don't know if the 40th bit is used for anything? FWIW this is completely up to the CPU. "Classical" ECC is completely transparent to the DIMM, it just remembers and returns what the CPU gave to it. 32 → 40 has already been around for quite some time (particularly when the DDR controller only has 64 data lines but you still want ECC you can sometimes do 32+8 at half performance & max capacity) but I don't see anything beyond SECDED in the datasheets... (looked through some Freescale/NXP PowerPC bits)
    - Dylan16807 5y ago
      > FWIW this is completely up to the CPU. "Classical" ECC is completely transparent to the DIMM, it just remembers and returns what the CPU gave to it. True, but I guess I assumed normal ECC was standardized. Is it? > 32 → 40 has already been around for quite some time (particularly when the DDR controller only has 64 data lines but you still want ECC Is that keeping a burst length of 8 on DDR3/DDR4? One thing to consider is that a full memory transfer plus 16 extra bits is much more useful than a smaller transfer with 8 extra bits. That could easily be a tipping point from "not worth bothering" to "they really should do something here".
      - eqvinox 5y ago
        > True, but I guess I assumed normal ECC was standardized. Is it? This is outside my area of expertise, but I believe everyone just does the same thing without it being a standard. (Especially since even CPU vendors frequently just buy a done-and-tested DDR controller design.) > Is that keeping a burst length of 8 on DDR3/DDR4? All the "classical" ECC just uses additional data lines, and I assumed DDR5 would do the same thing. I hadn't checked until a minute ago, but yes, DDR5 (like previous versions) just extends the width of the data bus by the ECC bits.

dogma1138 5y ago

That’s not exactly correct whilst it does there mainly to allow for higher densities and frequencies it’s designed to prevent bit flips from happening on chip. It’s not end to end ECC as in it doesn’t prevent flips that happen on the bus or in CPU cache but it does prevent single bit errors on DRAM.

eqvinox 5y ago
> it’s designed to prevent bit flips from happening on chip. Bit flips that are getting more and more common as the RAM cells are getting tinier and tinier, the stored charges ever smaller and smaller, and thus susceptible to flipping…

arcticbull 5y ago

I think on-chip ECC would mitigate this problem just as well as off-chip ECC. Off-chip ECC is meant to catch errors during transmission (i.e. 72 bits transmitted for 64 bit words), not necessarily just the ones that occur internal to the package. I agree it's meant to counter limitations due to increased density, but it should catch this to an extent also as this error is induced on-package right, not during transmission. Or am I mistaken?

monocasa 5y ago
I think the point the parent is making is that this ECC is already fixing errors. There's no redundancy because the redundancy is already consumed by the defective cells in the chip. Any additional flips such as through rowhammer have no extra redundancy to fall back on in the general case with DDR5's built-in ECC.
- arcticbull 5y ago
  Ah i see. I didn’t view the errors as additive. Thanks for the clarification!