41 ms·

> I cannot disable the patch to recuperate lost performance. Knowing the actual, demonstrated risks... why would you do this? I'm not trying to devalue your p

> I cannot disable the patch to recuperate lost performance. Knowing the actual, demonstrated risks... why would you do this? I'm not trying to devalue your position. I'm trying to understand your risk calculation. --- Edit: Good catch, humans. The thought of running code in an unexposed, isolated, largely trusted environment didn't cross my mind; I was moreso focused on the environments I'm used to (where everything is connected and nothing is trusted). That said, I'd argue that a database backend to any typical webapp definitely qualifies as exposed.

rndgermandude 8y ago
I'm going with the herd immunity for my personal stuff. The calculation is basically: their_waste = likelihood enough people have the mitigations enabled (not tech enough to disable them) so that "bad people" will not waste time developing exploits for the tiny number of unprotected people like me (herd protecting me) my_risk = likelihood of "bad people" actually finding me and being able to run their code their_reward = likelihood of them actually finding something meaningful and valuable in the memory they can manage to dump oops = (my_risk * their_reward) / their_waste I am assuming my_risk and their_reward to be low and their_waste to be high, so oops will be acceptably low (hopefully :p) Wish me luck!
- benologist 8y ago
  Server logs are full of scripts and people trying to penetrate services with old, known bugs that have been widely neutralized for years.... it doesn't cost much to try one exploit.
  - rndgermandude 8y ago
    So far there haven't any mass exploits for these CPU bugs targeting personal systems like mine in the wild. The most risk comes from web browsers as you can execute (constrained) attack code in those. That's why browser vendors were busy disabling SharedArrayBuffer real quick and developed further mitigations that hinder exploiting CPU bugs like these. I may reconsider when browser-based exploits become a real thing that is in widespread use. People probing my ports and exposed services running on my machines is far less of an issue since I don't run any service designed to run attacker supplied (but sandboxed) code like a browser does. If somebody managed to run code anyway (RCE) then I probably would have other problems than just worrying about somebody running spectre exploit code ;) As it stands right now, the prime targets are shared execution environments running untrusted sandboxed code, aka cloud providers needing to worry that customer A's VM doesn't dump the memory of customer B's VM running on the same hardware.
e1ven 8y ago
Not everyone is running any untrusted code. If you're running (for example) a physics simulation, the mitigation doesn't gain you much.
- w0utert 8y ago
  Fortunately the performance of these kinds of CPU-bound workloads are almost completely unaffected by the mitigations, so you might as well enable them anyway.
  - Filligree 8y ago
    One of them is "Disable hyperthreading," which absolutely has a severe penalty.
    - greglindahl 8y ago
      For some workloads.
    - germainelong 8y ago
      For some workloads it is better to have hyperthreading disabled.
  - gnufx 8y ago
    Actually, I've seend benchmarks to the contrary. As usual with benchmarks, there's no useful data to understand them -- specifically not performance counter data. I've yet to see a good analysis and haven't been able to do it myself. Many large-scale computations actually aren't CPU-bound, except insofar as they spin in MPI; some do plenty of filesystem i/o, but at least with something like PVFS2, that can be just in user-space on the compute node.
- gnufx 8y ago
  The sort of HPC clusters with which I'm familiar run plenty of what I'd call untrusted code, and are multi-access with arbitrary student users and not-infrequently-compromised credentials. That said, there seems to be a fairly small attack surface the way I'd set up compute nodes, even if they're not single-job/node; especially if maximum job times are a day or two. I probably wouldn't turn on the mitigations on compute nodes.
jakevn 8y ago
There are non-internet facing workloads that would benefit from the additional performance.
sl1ck731 8y ago
If it is on my personal machine I can't accept a 8-15% performance hit (I don't know the real impact thats just the first range I found).
dijit 8y ago
My database layer doesn’t run any untrusted code. I’d like the perf back there. Then audit the shit out of any users running there.
tux3 8y ago
Consider a server application that doesn't run arbitrary untrusted code and doesn't have meaningfully separate privilege levels. You can't leverage any speculation exploit without code execution, and there's nothing left to exploit on the box once you have a shell.
banachtarski 8y ago
The database backend does NOT qualify... If your DB machine is exposed to the outside world, using this exploit is overkill and there are plenty of other easier vectors of attack.
rayiner 8y ago
I thought these exploits already required code execution on your machine. (Maybe I'm wrong about that.) If untrusted code is already running on your machine, your system is already compromised. So I don't see the big deal about these exploits, except in the context of hosted VMs.
- zrm 8y ago
  It's not that they don't require code execution, it's that there is more code execution happening in things that are supposed to be sandboxed than most people generally anticipate. It's not just VMs. For example, how many of the map editors for various games are Turing-complete? If you download a custom map from random peer, you may be executing "sandboxed" code. Can it pull off a timing attack? And the elephant is presumably javascript.
  - rndgermandude 8y ago
    You'd still need a communication channel to the outside world that is available to the attack code/map or else it cannot exfiltrate the data it dumped.
    - zrm 8y ago
      In a multiplayer game where each of the peers is constantly sending the others data, that seems like a surmountable problem.
      - rndgermandude 8y ago
        The map engine "executing" the map has no access to the network layer of the game; or at least it shouldn't.
        lotyrin 8y ago
        what games don't have maps with manipulable objects that would need to have their state synced over the network? A barrel existing/having been exploded is one bit, the precise position of an object is quite a few more, etc.
LeifCarrotson 8y ago
I completely agree when it comes to running, say, a VPS. If you're running (or using) a service where thousands of businesses rely on the ability to run their code and their data on your machines without any of your other customers being able to access it, yeah, security is priority #1. On my personal workstation, though, what are they going to get? My credit card number? That's my bank's problem. I'm not particularly worried about targetted attacks, if my competitor or customers got everything on my hard drive little would change for any of us. Force me to restore from backup? Email password would be bad, but that's partially what 2-factor is for. I have a tiny chance of getting a few hours of inconvenience if someone completely owns my PC. That's not worth all my work happening a little bit slower all the time.
- zerkten 8y ago
  > On my personal workstation, though, what are they going to get? I think it depends on the context. I felt similarly until I discovered just how many machines attackers would pivot through in real-world attacks featuring strong adversaries. Preventing these attacks on every machine is a strength-in-depth measure.
- eganist 8y ago
  > what are they going to get? Your data is likely less important in that context compared to your device as a fractional resource or a pivot. (which I believe is largely zerkten's point)
shados 8y ago
I'm talking out of my behind here, but I was always under the impression some stuff we use casually is built with the assumption it's not under heavy attack, too. Eg: I thought consumer grade videocards were pretty darn insecure. I don't know where I picked that idea, but if that's true, then the idea of having the option to run "insecurely" for certain things make sense. Not sure if we can trust an average user with this, but if the videocard thing is true, we do.
CamperBob2 8y ago
Simple. I'm pretty sure I won't be the first to fall victim to an exploit that is purely academic at this point. Why on earth should I take a large performance penalty on my own PC to mitigate an attack that I'm pretty sure (a) will never be a problem for me and (b) that will almost certainly arrive with plenty of warning if it does? This whole business is massively, massively overhyped from the point of view of individual workstation users. Not every system needs to be locked down like NORAD. Doing so is a failure of basic threat modeling.

rndgermandude 8y ago

I'm going with the herd immunity for my personal stuff. The calculation is basically: their_waste = likelihood enough people have the mitigations enabled (not tech enough to disable them) so that "bad people" will not waste time developing exploits for the tiny number of unprotected people like me (herd protecting me) my_risk = likelihood of "bad people" actually finding me and being able to run their code their_reward = likelihood of them actually finding something meaningful and valuable in the memory they can manage to dump oops = (my_risk * their_reward) / their_waste I am assuming my_risk and their_reward to be low and their_waste to be high, so oops will be acceptably low (hopefully :p) Wish me luck!

benologist 8y ago
Server logs are full of scripts and people trying to penetrate services with old, known bugs that have been widely neutralized for years.... it doesn't cost much to try one exploit.
- rndgermandude 8y ago
  So far there haven't any mass exploits for these CPU bugs targeting personal systems like mine in the wild. The most risk comes from web browsers as you can execute (constrained) attack code in those. That's why browser vendors were busy disabling SharedArrayBuffer real quick and developed further mitigations that hinder exploiting CPU bugs like these. I may reconsider when browser-based exploits become a real thing that is in widespread use. People probing my ports and exposed services running on my machines is far less of an issue since I don't run any service designed to run attacker supplied (but sandboxed) code like a browser does. If somebody managed to run code anyway (RCE) then I probably would have other problems than just worrying about somebody running spectre exploit code ;) As it stands right now, the prime targets are shared execution environments running untrusted sandboxed code, aka cloud providers needing to worry that customer A's VM doesn't dump the memory of customer B's VM running on the same hardware.

e1ven 8y ago

Not everyone is running any untrusted code. If you're running (for example) a physics simulation, the mitigation doesn't gain you much.

w0utert 8y ago
Fortunately the performance of these kinds of CPU-bound workloads are almost completely unaffected by the mitigations, so you might as well enable them anyway.
- Filligree 8y ago
  One of them is "Disable hyperthreading," which absolutely has a severe penalty.
  - greglindahl 8y ago
    For some workloads.
  - germainelong 8y ago
    For some workloads it is better to have hyperthreading disabled.
- gnufx 8y ago
  Actually, I've seend benchmarks to the contrary. As usual with benchmarks, there's no useful data to understand them -- specifically not performance counter data. I've yet to see a good analysis and haven't been able to do it myself. Many large-scale computations actually aren't CPU-bound, except insofar as they spin in MPI; some do plenty of filesystem i/o, but at least with something like PVFS2, that can be just in user-space on the compute node.
gnufx 8y ago
The sort of HPC clusters with which I'm familiar run plenty of what I'd call untrusted code, and are multi-access with arbitrary student users and not-infrequently-compromised credentials. That said, there seems to be a fairly small attack surface the way I'd set up compute nodes, even if they're not single-job/node; especially if maximum job times are a day or two. I probably wouldn't turn on the mitigations on compute nodes.

jakevn 8y ago

There are non-internet facing workloads that would benefit from the additional performance.

sl1ck731 8y ago

If it is on my personal machine I can't accept a 8-15% performance hit (I don't know the real impact thats just the first range I found).

dijit 8y ago

My database layer doesn’t run any untrusted code. I’d like the perf back there. Then audit the shit out of any users running there.

tux3 8y ago

Consider a server application that doesn't run arbitrary untrusted code and doesn't have meaningfully separate privilege levels. You can't leverage any speculation exploit without code execution, and there's nothing left to exploit on the box once you have a shell.

banachtarski 8y ago

The database backend does NOT qualify... If your DB machine is exposed to the outside world, using this exploit is overkill and there are plenty of other easier vectors of attack.

rayiner 8y ago

I thought these exploits already required code execution on your machine. (Maybe I'm wrong about that.) If untrusted code is already running on your machine, your system is already compromised. So I don't see the big deal about these exploits, except in the context of hosted VMs.

zrm 8y ago
It's not that they don't require code execution, it's that there is more code execution happening in things that are supposed to be sandboxed than most people generally anticipate. It's not just VMs. For example, how many of the map editors for various games are Turing-complete? If you download a custom map from random peer, you may be executing "sandboxed" code. Can it pull off a timing attack? And the elephant is presumably javascript.
- rndgermandude 8y ago
  You'd still need a communication channel to the outside world that is available to the attack code/map or else it cannot exfiltrate the data it dumped.
  - zrm 8y ago
    In a multiplayer game where each of the peers is constantly sending the others data, that seems like a surmountable problem.
    - rndgermandude 8y ago
      The map engine "executing" the map has no access to the network layer of the game; or at least it shouldn't.
      - lotyrin 8y ago
        what games don't have maps with manipulable objects that would need to have their state synced over the network? A barrel existing/having been exploded is one bit, the precise position of an object is quite a few more, etc.

LeifCarrotson 8y ago

I completely agree when it comes to running, say, a VPS. If you're running (or using) a service where thousands of businesses rely on the ability to run their code and their data on your machines without any of your other customers being able to access it, yeah, security is priority #1. On my personal workstation, though, what are they going to get? My credit card number? That's my bank's problem. I'm not particularly worried about targetted attacks, if my competitor or customers got everything on my hard drive little would change for any of us. Force me to restore from backup? Email password would be bad, but that's partially what 2-factor is for. I have a tiny chance of getting a few hours of inconvenience if someone completely owns my PC. That's not worth all my work happening a little bit slower all the time.

zerkten 8y ago
> On my personal workstation, though, what are they going to get? I think it depends on the context. I felt similarly until I discovered just how many machines attackers would pivot through in real-world attacks featuring strong adversaries. Preventing these attacks on every machine is a strength-in-depth measure.
eganist 8y ago
> what are they going to get? Your data is likely less important in that context compared to your device as a fractional resource or a pivot. (which I believe is largely zerkten's point)

shados 8y ago

I'm talking out of my behind here, but I was always under the impression some stuff we use casually is built with the assumption it's not under heavy attack, too. Eg: I thought consumer grade videocards were pretty darn insecure. I don't know where I picked that idea, but if that's true, then the idea of having the option to run "insecurely" for certain things make sense. Not sure if we can trust an average user with this, but if the videocard thing is true, we do.

CamperBob2 8y ago

Simple. I'm pretty sure I won't be the first to fall victim to an exploit that is purely academic at this point. Why on earth should I take a large performance penalty on my own PC to mitigate an attack that I'm pretty sure (a) will never be a problem for me and (b) that will almost certainly arrive with plenty of warning if it does? This whole business is massively, massively overhyped from the point of view of individual workstation users. Not every system needs to be locked down like NORAD. Doing so is a failure of basic threat modeling.