4 ms·

I’m trying to understand how the attack was successful on Apple M1 ARM CPUs. I’ll keep reading, but if anyone has any insights please share!

ddworken 6y ago
Fundamentally, Spectre is a class of bugs that arises from how modern CPUs are designed. It isn't just an Intel bug, an x86 bug, or a JS bug. CPUs that perform speculative execution after a branch prediction are generally expected to be vulnerable. And as I understand it (I'm a security person, not a CPU designer) branch prediction is a very important optimization that is responsible for a lot of the advances in CPU performance over the years. So if CPU designers dropped branch prediction, they'd be trading off a lot of speed for security.
- cyberlurker 6y ago
  Thanks, that seems to align with what I understand too. But I thought perhaps a new architecture, like M1, would have had some additional protection.
  - touisteur 6y ago
    But can you drop it on a per-thread or per-process or per-core basis? That would help, no?
    - ddworken 6y ago
      What do you mean by "drop it"? I guess I could imagine that a CPU would allow a specific process to disable speculative execution. That could be an interesting feature though I'm skeptical that any real world applications would actually want to opt-out of speculative execution if it makes things drastically.
      - touisteur 6y ago
        Well that depends on your app/system and how much processing you do for each network interaction. Some of us don't really receive and parse 67 billions HTTP requests + json every second. If tail/mean latency increases a bit, well, let's concentrate HW to avoid network interactions, at least network reception/parsing. Just looking for a way out of the mitigation quagmire for people/orgs who own the hardware and don't share it with external untrusted parties. For all the talk about threat modelling, everyone seems to think we all want -20% perf on the whole machine, while only one or two processes do net I/O...

ddworken 6y ago

Fundamentally, Spectre is a class of bugs that arises from how modern CPUs are designed. It isn't just an Intel bug, an x86 bug, or a JS bug. CPUs that perform speculative execution after a branch prediction are generally expected to be vulnerable. And as I understand it (I'm a security person, not a CPU designer) branch prediction is a very important optimization that is responsible for a lot of the advances in CPU performance over the years. So if CPU designers dropped branch prediction, they'd be trading off a lot of speed for security.

cyberlurker 6y ago
Thanks, that seems to align with what I understand too. But I thought perhaps a new architecture, like M1, would have had some additional protection.
- touisteur 6y ago
  But can you drop it on a per-thread or per-process or per-core basis? That would help, no?
  - ddworken 6y ago
    What do you mean by "drop it"? I guess I could imagine that a CPU would allow a specific process to disable speculative execution. That could be an interesting feature though I'm skeptical that any real world applications would actually want to opt-out of speculative execution if it makes things drastically.
    - touisteur 6y ago
      Well that depends on your app/system and how much processing you do for each network interaction. Some of us don't really receive and parse 67 billions HTTP requests + json every second. If tail/mean latency increases a bit, well, let's concentrate HW to avoid network interactions, at least network reception/parsing. Just looking for a way out of the mitigation quagmire for people/orgs who own the hardware and don't share it with external untrusted parties. For all the talk about threat modelling, everyone seems to think we all want -20% perf on the whole machine, while only one or two processes do net I/O...