9 ms·

For any yung'uns seeing this for the first time, the spectre and meltdown attacks (and accompanying papers) are worth reading. https://spectreattack.com/ https

For any yung'uns seeing this for the first time, the spectre and meltdown attacks (and accompanying papers) are worth reading. https://spectreattack.com/ https://spectreattack.com/

ajross 2y ago
Hm... as I read it this is much worse. Spectre/Meltdown were data isolation vulnerabilities. You could exploit side channel (mostly timing) information to intuit state about memory across a protection boundary. Basically you can prime the CPU state to allow you to tell which of multiple code paths the kernel/hypervisor/whatever took, and then go from there to reading arbitrary data. Which is bad, obviously. Here, they claim to have a remote exploit vulnerability. It's not that Apple is leaking data, it's that the CPUs have a bug where they appear to be actually executing code based on incorrectly-loaded ("predicted") data. Though the details are, as is usually the case, thin. I await further analysis.
- saagarjha 2y ago
  They’re speculatively executing code. It’s not traditional code execution. (You can, of course, read the papers for full details.)
- omcnoe 2y ago
  It's not remote code execution, it's the same flavor of "out of bounds read through speculation" as previous vulnerabilities. It's terrifying because they have a working proof of concept from untrusted JS in Safari, but there have been speculative execution in browser JS engines before now also.
  - ajross 2y ago
    The language seems to argue otherwise: SLAP "allows the adversary to jump the LAP to the target webpage's string and trick the CPU into operating on it" and FLOP "allows us to run a function with the wrong arguments". That's absolutely not mere data exfiltration. Now, maybe this is because of a trampoline based on pre-existing Safari bugs and not the CPU misfeature itself. Again, the details are slim. But "the same flavor of vulerability" seems to be a mischaracterization.
    - saagarjha 2y ago
      No, they’re correct.
    - loeg 2y ago
      Only speculatively. The end result is the same as not executing that code, other than observable side effects.
    - yencabulator 2y ago
      My read: the attack gets 600 cycles of CPU time to execute its code (JITted Javascript, in web context) on the speculated data, and to use some side channel to communicate results back out of the speculated parallel-world. Some of the earlier speculation attacks didn't get to do arbitrary compute on the speculated data, they could only for example influence whether something was loaded into cache or not. This makes an attack easier to write.
- midtake 2y ago
  A browser-based attack, in theory, could have happened with Spectre/Meltdown as well. I seem to recall a PoC for Spectre in the browser, actually. I believe it's also a reason that microsecond precision in the browser was made a bit more opaque since that era.
  - mettamage 2y ago
    GLitch was a Rowhammer browser based attack [1]. It's not Spectre/Meltdown but still, for a while people thought it couldn't be done. [1] https://www.vusec.net/projects/glitch/ https://www.vusec.net/projects/glitch/
umvi 2y ago
Is it bad that I disable spectre mitigations on all my PCs to get a free double-digit-% performance boost?
- kllrnohj 2y ago
  What are you doing where you see anything remotely close to double-digit-% gains from disabling spectre mitigations?
  - umvi 2y ago
    my specific use case where I see significant performance improvement is image segmentation pipelines (which involve opencv-style image processing and AI inference). YMMV depending on your CPU I suppose.
  - iforgot22 2y ago
    Video editing maybe? Which is not going to involve running untrusted code.
    - kllrnohj 2y ago
      It's not going to hammer on syscalls, either, so it won't have any spectre-related regressions.
  - AHTERIX5000 2y ago
    If mitigations include disabling SMT and the workload is compiling code, then the difference is easily in double digits.
    - kllrnohj 2y ago
      What OS ships the mitigation of disabling SMT by default? Surely they just meant things like the retpoline mitigations in syscalls?
- baq 2y ago
  Only if you don't care if baddies see you go fast
LPisGood 2y ago
I’d highly recommend reading Flush+Reload first since the cache side channel is key to any of these miceoarchitectural attacks.
- mettamage 2y ago
  As someone who followed a course on all of this, this is indeed how we started out. 1. Read Flush + Reload 2. Then reproduce it in C 3. Then read Meltdown 4. Reproduce it in C 5. Read Spectre 6. Reproduce it in C After that we had to implement a VUSEC paper. I chose GLitch [1]. [1] https://www.vusec.net/projects/glitch/ https://www.vusec.net/projects/glitch/
  - sabas123 2y ago
    Keep in mind that getting meltdown to work might be very difficult depending on your setup. I wouldn't have been able to at least when starting out my teacher didn't provide us with targetable hardware. A spectre (particularly RSB-based ones) are nice to start out with imo.
    - mettamage 2y ago
      Yea fair, this is obviously a high level overview. I think I found with meltdown that I needed the assembly code. I also was able to reproduce it with actual C code if I recall correctly but that was way more finnicky.

For any yung'uns seeing this for the first time, the spectre and meltdown attacks (and accompanying papers) are worth reading. https://spectreattack.com/ https://spectreattack.com/

ajross 2y ago

Hm... as I read it this is much worse. Spectre/Meltdown were data isolation vulnerabilities. You could exploit side channel (mostly timing) information to intuit state about memory across a protection boundary. Basically you can prime the CPU state to allow you to tell which of multiple code paths the kernel/hypervisor/whatever took, and then go from there to reading arbitrary data. Which is bad, obviously. Here, they claim to have a remote exploit vulnerability. It's not that Apple is leaking data, it's that the CPUs have a bug where they appear to be actually executing code based on incorrectly-loaded ("predicted") data. Though the details are, as is usually the case, thin. I await further analysis.

saagarjha 2y ago
They’re speculatively executing code. It’s not traditional code execution. (You can, of course, read the papers for full details.)
omcnoe 2y ago
It's not remote code execution, it's the same flavor of "out of bounds read through speculation" as previous vulnerabilities. It's terrifying because they have a working proof of concept from untrusted JS in Safari, but there have been speculative execution in browser JS engines before now also.
- ajross 2y ago
  The language seems to argue otherwise: SLAP "allows the adversary to jump the LAP to the target webpage's string and trick the CPU into operating on it" and FLOP "allows us to run a function with the wrong arguments". That's absolutely not mere data exfiltration. Now, maybe this is because of a trampoline based on pre-existing Safari bugs and not the CPU misfeature itself. Again, the details are slim. But "the same flavor of vulerability" seems to be a mischaracterization.
  - saagarjha 2y ago
    No, they’re correct.
  - loeg 2y ago
    Only speculatively. The end result is the same as not executing that code, other than observable side effects.
  - yencabulator 2y ago
    My read: the attack gets 600 cycles of CPU time to execute its code (JITted Javascript, in web context) on the speculated data, and to use some side channel to communicate results back out of the speculated parallel-world. Some of the earlier speculation attacks didn't get to do arbitrary compute on the speculated data, they could only for example influence whether something was loaded into cache or not. This makes an attack easier to write.
midtake 2y ago
A browser-based attack, in theory, could have happened with Spectre/Meltdown as well. I seem to recall a PoC for Spectre in the browser, actually. I believe it's also a reason that microsecond precision in the browser was made a bit more opaque since that era.
- mettamage 2y ago
  GLitch was a Rowhammer browser based attack [1]. It's not Spectre/Meltdown but still, for a while people thought it couldn't be done. [1] https://www.vusec.net/projects/glitch/ https://www.vusec.net/projects/glitch/

umvi 2y ago

Is it bad that I disable spectre mitigations on all my PCs to get a free double-digit-% performance boost?

kllrnohj 2y ago
What are you doing where you see anything remotely close to double-digit-% gains from disabling spectre mitigations?
- umvi 2y ago
  my specific use case where I see significant performance improvement is image segmentation pipelines (which involve opencv-style image processing and AI inference). YMMV depending on your CPU I suppose.
- iforgot22 2y ago
  Video editing maybe? Which is not going to involve running untrusted code.
  - kllrnohj 2y ago
    It's not going to hammer on syscalls, either, so it won't have any spectre-related regressions.
- AHTERIX5000 2y ago
  If mitigations include disabling SMT and the workload is compiling code, then the difference is easily in double digits.
  - kllrnohj 2y ago
    What OS ships the mitigation of disabling SMT by default? Surely they just meant things like the retpoline mitigations in syscalls?
baq 2y ago
Only if you don't care if baddies see you go fast

LPisGood 2y ago

I’d highly recommend reading Flush+Reload first since the cache side channel is key to any of these miceoarchitectural attacks.

mettamage 2y ago
As someone who followed a course on all of this, this is indeed how we started out. 1. Read Flush + Reload 2. Then reproduce it in C 3. Then read Meltdown 4. Reproduce it in C 5. Read Spectre 6. Reproduce it in C After that we had to implement a VUSEC paper. I chose GLitch [1]. [1] https://www.vusec.net/projects/glitch/ https://www.vusec.net/projects/glitch/
- sabas123 2y ago
  Keep in mind that getting meltdown to work might be very difficult depending on your setup. I wouldn't have been able to at least when starting out my teacher didn't provide us with targetable hardware. A spectre (particularly RSB-based ones) are nice to start out with imo.
  - mettamage 2y ago
    Yea fair, this is obviously a high level overview. I think I found with meltdown that I needed the assembly code. I also was able to reproduce it with actual C code if I recall correctly but that was way more finnicky.