4 ms·

The post seems to be slightly confused about the Arm DSB and ISB instructions. These don't affect the caches at all -- they are barriers, which affect ordering

by pm215 8y ago

The post seems to be slightly confused about the Arm DSB and ISB instructions. These don't affect the caches at all -- they are barriers, which affect ordering and pipelining. DSB says "don't go any further until all memory accesses made by instructions before this one have completed", and ISB says "flush the pipeline so the next insn is reread from the cache" (among other things). So self-modifying and other tricky code needs to consider these insn ordering issues as well as cache manipulation, and barrier insns aren't a substitute for doing the cache maintenance.

ajross 8y ago
Pipeline control certainly does effect caches. That's where the memory access being controlled goes. I mean, it's tempting to try to understand them as an orthogonal thing, but in fact memory hierarchies and CPU pipelines (and other stuff like store forward buffers) are tied at the hip and it's pointless to try to "understand" them in isolation. At best it's an exercise in specification pedantry. The only reason instruction barriers, fences and serialization instructions seem to make sense in docs is that someone at the architecture sat down and wrote a memory and execution model that can be abstracted by whatever API it is they present to the user. And someone doing performance or exploitation work at the level of the linked article really needs to understand that model, not the API. (Though you're absolutely right that this particular article seems to be a bit mixed up about both)
- pm215 8y ago
  I meant that it doesn't affect it in the sense that it doesn't change the way the cache behaves or ask it to flush or invalidate any of its contents. You can have a pipelined CPU which needs the barrier insns but which has no cache at all (most likely in embedded). And if the problem you're having is that your data is in the dcache but not the icache then the barrier insns won't help, because they're not architecturally defined to do that. I certainly agree that you need to understand the architectural model to write reliable (and cross-cpu portable code) -- and the architectural model for Arm does distinguish barriers from cache maintenance -- though if you're writing exploit shellcode then "works most of the time and we can't do better given the way the bug we're exploiting to get code execution" is sometimes what you're going to end up with, at which point knowing what the specific hardware is doing can help.

by pm215 8y ago

ajross 8y ago

Pipeline control certainly does effect caches. That's where the memory access being controlled goes. I mean, it's tempting to try to understand them as an orthogonal thing, but in fact memory hierarchies and CPU pipelines (and other stuff like store forward buffers) are tied at the hip and it's pointless to try to "understand" them in isolation. At best it's an exercise in specification pedantry. The only reason instruction barriers, fences and serialization instructions seem to make sense in docs is that someone at the architecture sat down and wrote a memory and execution model that can be abstracted by whatever API it is they present to the user. And someone doing performance or exploitation work at the level of the linked article really needs to understand that model, not the API. (Though you're absolutely right that this particular article seems to be a bit mixed up about both)

pm215 8y ago
I meant that it doesn't affect it in the sense that it doesn't change the way the cache behaves or ask it to flush or invalidate any of its contents. You can have a pipelined CPU which needs the barrier insns but which has no cache at all (most likely in embedded). And if the problem you're having is that your data is in the dcache but not the icache then the barrier insns won't help, because they're not architecturally defined to do that. I certainly agree that you need to understand the architectural model to write reliable (and cross-cpu portable code) -- and the architectural model for Arm does distinguish barriers from cache maintenance -- though if you're writing exploit shellcode then "works most of the time and we can't do better given the way the bug we're exploiting to get code execution" is sometimes what you're going to end up with, at which point knowing what the specific hardware is doing can help.