3 ms·

This is a scary place to be: the top-level debug resource for a major project. It took almost two years to resolve, but was already known as SKL150. Looking at

This is a scary place to be: the top-level debug resource for a major project. It took almost two years to resolve, but was already known as SKL150. Looking at the clang vs. gcc assembly without knowledge of SKL150 would be literally impossible to debug. GCC -O1 vs -O2 is a clue, but even with the asm diffs, wth? Again, scary.

tinus_hn 5y ago
The world is a scary place; this is basically the same as rowhammer which is an issue in computers shipped today.
- woodruffw 5y ago
  Unless I'm misunderstanding what you mean, this isn't really like rowhammer at all -- it's a uarch/ucode bug, which is effectively a programming error within the CPU. Rowhammer is a physical flaw in how memory cells in DRAM are laid out, one that can be triggered by memory access patterns independent of CPU architecture and microarchitecture. (There are also hundreds of errata like this one in every CPU generation. They're usually not easy to exploit, since they cause system instability rather than disclosing secret material or allowing unintended code execution.)
  - zsmi 5y ago
    > Rowhammer is a physical flaw in how memory cells in DRAM are laid out It's not really a flaw, more like a consequence of how memory cells are laid out. I mean most people want lots of bits in their DRAM. Maximizing this parameter necessitates that some will be in close proximity.
    - woodruffw 5y ago
      To my (non-EE) mind, the flaw is the electrical leakage between the cells. Tight packing is a consequence of economic forces, but I assume there are also technical solutions that allow for tight packing (but either offset the performance or cost gains). Is that assumption wrong? (Genuinely asking!)
      - zsmi 5y ago
        There was a good paper on it in 2014. [1] They describe the RowHammer attack as: opening and closing (activation and precharge) a DRAM row (aggressor row) at a high enough rate (hammering) such that it can cause bit-flips in physically nearby rows (victim row). Colloquially, it's basically a change in voltage in one place can indirectly cause a change in voltage in another place via capacitive coupling. Capacitance increases proportional to the inverse of the separating distance so only in recent years have things shrunk to the size that makes it an issue. Since having less bits in DRAM is basically not an option most mitigation techniques that I know of remove the possibility of hammering: possibilities include the OS, memory system controller, or DRAM controller changes. [1] https://users.ece.cmu.edu/~yoonguk/papers/kim-isca14.pdf https://users.ece.cmu.edu/~yoonguk/papers/kim-isca14.pdf
        woodruffw 5y ago
        Much appreciated, thank you.
      - tlb 5y ago
        DRAM cells also decay over time (~ 60 milliseconds), but memory controllers have some logic to refresh every row on a regular schedule so it's not an issue. They should also have logic to refresh adjacent rows if some number of consecutive accesses to a small group of rows is detected. This is rare in normal workloads, because those accesses normally come from cache. It's lame of chipmakers to not fix this. The fix would requires the DRAM controller (integrated into modern CPUs) to know more about the internals of DRAMs than they currently do.
        zsmi 5y ago
        In theory DDR5/LPDDR5 added a controller command for RowHammer mitigation but I haven't had time to research it yet. See: https://arxiv.org/pdf/2108.06703.pdf https://arxiv.org/pdf/2108.06703.pdf
  - tinus_hn 5y ago
    This is a flaw that randomly causes unpredictable things to happen if you rapidly put things in registers. That doesn’t look like a programming error to me.
    - woodruffw 5y ago
      You’ve never seen a programming error triggered by a user rapidly mutating state? The programming in question here is ucode instead of application code, but it’s programming nonetheless.
      - tinus_hn 5y ago
        Do you have an example of that? All I can think of are weird edge cases with animations.
        woodruffw 5y ago
        The canonical example that I can think of is the entire "race condition" bug class. But also TOCTTOU, caching bugs, &c. (all of which are arguably also in the race condition category.)
- deleted 5y ago
  [deleted]

tinus_hn 5y ago

The world is a scary place; this is basically the same as rowhammer which is an issue in computers shipped today.

woodruffw 5y ago
Unless I'm misunderstanding what you mean, this isn't really like rowhammer at all -- it's a uarch/ucode bug, which is effectively a programming error within the CPU. Rowhammer is a physical flaw in how memory cells in DRAM are laid out, one that can be triggered by memory access patterns independent of CPU architecture and microarchitecture. (There are also hundreds of errata like this one in every CPU generation. They're usually not easy to exploit, since they cause system instability rather than disclosing secret material or allowing unintended code execution.)
- zsmi 5y ago
  > Rowhammer is a physical flaw in how memory cells in DRAM are laid out It's not really a flaw, more like a consequence of how memory cells are laid out. I mean most people want lots of bits in their DRAM. Maximizing this parameter necessitates that some will be in close proximity.
  - woodruffw 5y ago
    To my (non-EE) mind, the flaw is the electrical leakage between the cells. Tight packing is a consequence of economic forces, but I assume there are also technical solutions that allow for tight packing (but either offset the performance or cost gains). Is that assumption wrong? (Genuinely asking!)
    - zsmi 5y ago
      There was a good paper on it in 2014. [1] They describe the RowHammer attack as: opening and closing (activation and precharge) a DRAM row (aggressor row) at a high enough rate (hammering) such that it can cause bit-flips in physically nearby rows (victim row). Colloquially, it's basically a change in voltage in one place can indirectly cause a change in voltage in another place via capacitive coupling. Capacitance increases proportional to the inverse of the separating distance so only in recent years have things shrunk to the size that makes it an issue. Since having less bits in DRAM is basically not an option most mitigation techniques that I know of remove the possibility of hammering: possibilities include the OS, memory system controller, or DRAM controller changes. [1] https://users.ece.cmu.edu/~yoonguk/papers/kim-isca14.pdf https://users.ece.cmu.edu/~yoonguk/papers/kim-isca14.pdf
      - woodruffw 5y ago
        Much appreciated, thank you.
    - tlb 5y ago
      DRAM cells also decay over time (~ 60 milliseconds), but memory controllers have some logic to refresh every row on a regular schedule so it's not an issue. They should also have logic to refresh adjacent rows if some number of consecutive accesses to a small group of rows is detected. This is rare in normal workloads, because those accesses normally come from cache. It's lame of chipmakers to not fix this. The fix would requires the DRAM controller (integrated into modern CPUs) to know more about the internals of DRAMs than they currently do.
      - zsmi 5y ago
        In theory DDR5/LPDDR5 added a controller command for RowHammer mitigation but I haven't had time to research it yet. See: https://arxiv.org/pdf/2108.06703.pdf https://arxiv.org/pdf/2108.06703.pdf
- tinus_hn 5y ago
  This is a flaw that randomly causes unpredictable things to happen if you rapidly put things in registers. That doesn’t look like a programming error to me.
  - woodruffw 5y ago
    You’ve never seen a programming error triggered by a user rapidly mutating state? The programming in question here is ucode instead of application code, but it’s programming nonetheless.
    - tinus_hn 5y ago
      Do you have an example of that? All I can think of are weird edge cases with animations.
      - woodruffw 5y ago
        The canonical example that I can think of is the entire "race condition" bug class. But also TOCTTOU, caching bugs, &c. (all of which are arguably also in the race condition category.)
deleted 5y ago
[deleted]