7 ms·

Running the below over my machines gives me back the 8-30% cycles I originally paid for, depending on load type. This will have to do until everything is swappe

Running the below over my machines gives me back the 8-30% cycles I originally paid for, depending on load type. This will have to do until everything is swapped to AMD. Note you only need 'mitigations=off' in later kernels. - name: Disable CPU-sapping security mitigations become: yes lineinfile: path: /etc/default/grub line: GRUB_CMDLINE_LINUX_DEFAULT="noresume noibrs noibpb nopti nospectre_v2 nospectre_v1 l1tf=off nospec_store_bypass_disable no_stf_barrier mds=off mitigations=off" - name: Update grub become: yes command: /usr/sbin/grub-mkconfig -o /boot/grub/grub.cfg No I don't give a fuck about the 'risk' this introduces, but I expect my bank to.

wolf550e 7y ago
Your web browser runs untrusted code. On a computer that never runs untrusted code you can do that.
- scandinavian 7y ago
  There have been more Chrome/Firefox 0-days than speculative execution vulnerabilities exploitable in Javascript (0). Sure, there is a chance that the Chrome/Firefox teams missed something, but there have been sighted no exploits since the release (of spectrev1) and the browser fixes. It's not a crazy threat model to have on a personal PC, the risk is so very minimal. If your threat model is that strict you shouldn't be running JS anyway.
  - dijit 7y ago
    What are you even talking about? the introduction to this problem came with a proof-of-concept _IN JAVASCRIPT_.[0] Session keys, private keys, passwords and all other kinds of access tokens that your system is using, it's the next worst thing from remote code execution. Your browser runs so much untrusted code that it's really unreasonable, and yes, we should definitely be pushing back hard on this. But it's probably the most stupid thing you can do to disable these mitigations because they're not just theoretical, they're real, they're here and everyone knows about them. This is like anti-vaxx philosophy. "the risk is low"; well, maybe the risk is low because of herd immunity, it's not feasible to run these attacks as they'll be obvious to those who have the mitigations in place (100% CPU), but if there's a 0.00000001% return then it becomes profitable to exploit, just like mail spam. Do not fucking turn off these mitigations on desktop computers, they are too complex and run untrusted code all the time. Unless you can work without javascript and I doubt you can because the web today is basically unusable without it. If you have a database which is only accessible internally, you can disable the mitigations, because those things are hit hardest by the mitigations and do not run untrusted code. But really, your desktop is running untrusted code _a lot_. Please do not do this, not only for your own sake but for everyones sake. Don't make it profitable for malicious agents to run these attacks. [0]: https://www.reddit.com/r/javascript/comments/7ob6a2/spectre_and_meltdown_exploit_javascript_example/ https://www.reddit.com/r/javascript/comments/7ob6a2/spectre_...
    - jotm 7y ago
      Ha, I had the same thought, comparing this to antivaxxers. The downsides are of course, infinitely lower (stolen password vs disability or death), but yeah the similarity is there. We've yet to see a real world attack using any of these, however.
    - scandinavian 7y ago
      From the comment in your link: > It's missing the entire actual implementation of the Spectre attack, which requires analysis of read times to see if you're hitting the processor cache or not. "analysis of read times" is what the browsers "fixed" to mitigate the attacks (and site isolation later). Again, there has been no working attacks on updated browsers. Please feel free to link an example of one though, I will gladly admit I'm wrong. You just seem to frankly have no idea how the exploits actually work though (did you actually read the code in the reddit post?), so I suspect that this conversation will be a waste of time.
      - dijit 7y ago
        The browser mitigation’s only work with the kernel mitigation’s. Neither is working well without the other. And yes. I’m very well versed on this topic.
        scandinavian 7y ago
        >The browser mitigation’s only work with the kernel mitigation’s. That's just not true. The timer precision doesn't have anything to do with the kernel mitigations.
        dijit 7y ago
        The timing precision thing by itself doesn't twarte anything, it just makes the attacks harder or take more time. The browser vendors themselves said this; and it's not a permanent solution as tech such as Stadia and WebVR rely on high precision timers. But, whatever man, I'm telling you that it's stupid and you want to bury your head in the sand. You just make these attacks more likely; I'm not going to be impacted except for a few trillion CPU cycles of idiots trying to exploit me. You're the one who puts their entire digital life on the line by eking out 5% performance.
  - Grangar 7y ago
    Browser 0-days still often run on user priviledges. The moment you get code-execution on a vulnerable Intel CPU that turns into hardware level access. And like the other commenter said, there are also JS implementations.
    - deleted 7y ago
      [deleted]
  - MiroF 7y ago
    > There have been more Chrome/Firefox 0-days than speculative execution vulnerabilities exploitable in Javascript (0). sure dude, sure
    - scandinavian 7y ago
      Chrome: CVE-2019-13720, CVE-2019-5786 Firefox: CVE-2019-11707/CVE-2019-11708 Your turn. Link the speculative execution 0days.
      - MiroF 7y ago
        Here's an example of post-mitigation reading of protected memory using Javascript and Spectre https://alephsecurity.com/2018/06/26/spectre-browser-query-cache/ https://alephsecurity.com/2018/06/26/spectre-browser-query-c... I think it's just silly that you would rely on browser mitigations like disabling high precision timers when that's obviously just a hack.
        scandinavian 7y ago
        As is said in the PoC, it does not bypass index masking and site-isolation. They read data already available to the code they are executing. They did show that the timer resolution mitigation is not 100% effective, which is well known and why it is not the only mitigation. That's not a speculative execution browser 0day, as it doesn't work in updated browsers and it never has (or I guess it works if you want to leak data you could just console.log). Could you post an actual 0day instead?
- nullc 7y ago
  Not every computer runs a web browser. Of the hundreds of high performance cores I have, only a couple run a web browser. ... thought increasingly more of them are non-intel.
  - gpm 7y ago
    What about a network stack? Are they running one of those exposed to adversaries? http://www.misc0110.net/web/files/netspectre.pdf http://www.misc0110.net/web/files/netspectre.pdf
    - nullc 7y ago
      Very interesting link! but indeed, I have a lot of cores that are just on a private network.
coldtea 7y ago
>No I don't give a fuck about the 'risk' this introduces Well, let's hope you're not powned because of this and get dragged into giving some fucks, for a 5-10% of performance hit you wouldn't notice anyway...
- systemcluster 7y ago
  Anecdotally, the performance hit from the security mitigations since the Spectre/Meltdown publication has been very noticeable.
  - ageofwant 7y ago
    More anecdata: On my workloads, which involves moving large discrete image frames as part of a video inference ML pipeline through a message broker and other processing pipelines, de-mitigating decreased system loads ~25% on average. Some workloads up to 30% depending on inference model. So yes noticeable.
- ageofwant 7y ago
  Pray, why do you think I would expend the effort of deliberately increasing my 'exposure' if I did not notice the effects of these mitigation on my workloads ? And they are not particularly unique. Do you understand my risk and load requirements better than I do ? Have you entertained the possibility that the decision to de-mitigate was the result of considered risk and resource management modeling ? But thanks for your concern and all.
  - coldtea 7y ago
    >Pray, why do you think I would expend the effort of deliberately increasing my 'exposure' if I did not notice the effects of these mitigation on my workloads ? You'd be surprised what people would do. Could be just out of some spite ("fuck Intel"). Could not even include any measurable workloads ("I want my machine to go ultra fast"). >Do you understand my risk and load requirements better than I do ? For you particularly probably not, but you'd be surprised how many times a third party can "understand the risk and load requirements" of someone else (even a business) better than they do. E.g. the "No, you don't need a Hadoop cluster for doing "ML" on a 1GB file", phenomenon. >Have you entertained the possibility that the decision to de-mitigate was the result of considered risk and resource management modeling ? Only briefly, cause the tone of the comment made it sound more of a knee jerk reaction ("No I don't give a fuck about the 'risk' this introduces", "until everything is swapped to AMD") doesn't sound like the fruits of rational analysis...
uwydr 7y ago
You can do the same thing on Windows by using InSpectre: https://www.grc.com/inspectre.htm https://www.grc.com/inspectre.htm
yrro 7y ago
FYI, you can do the same thing with drop-in config files and avoid the annoying dpkg-conffile prompt whenever you upgrade grub2-common: $ cat /etc/default/grub.d/mitigations.cfg GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT mitigations=auto,nosmt"

wolf550e 7y ago

Your web browser runs untrusted code. On a computer that never runs untrusted code you can do that.

scandinavian 7y ago
There have been more Chrome/Firefox 0-days than speculative execution vulnerabilities exploitable in Javascript (0). Sure, there is a chance that the Chrome/Firefox teams missed something, but there have been sighted no exploits since the release (of spectrev1) and the browser fixes. It's not a crazy threat model to have on a personal PC, the risk is so very minimal. If your threat model is that strict you shouldn't be running JS anyway.
- dijit 7y ago
  What are you even talking about? the introduction to this problem came with a proof-of-concept _IN JAVASCRIPT_.[0] Session keys, private keys, passwords and all other kinds of access tokens that your system is using, it's the next worst thing from remote code execution. Your browser runs so much untrusted code that it's really unreasonable, and yes, we should definitely be pushing back hard on this. But it's probably the most stupid thing you can do to disable these mitigations because they're not just theoretical, they're real, they're here and everyone knows about them. This is like anti-vaxx philosophy. "the risk is low"; well, maybe the risk is low because of herd immunity, it's not feasible to run these attacks as they'll be obvious to those who have the mitigations in place (100% CPU), but if there's a 0.00000001% return then it becomes profitable to exploit, just like mail spam. Do not fucking turn off these mitigations on desktop computers, they are too complex and run untrusted code all the time. Unless you can work without javascript and I doubt you can because the web today is basically unusable without it. If you have a database which is only accessible internally, you can disable the mitigations, because those things are hit hardest by the mitigations and do not run untrusted code. But really, your desktop is running untrusted code _a lot_. Please do not do this, not only for your own sake but for everyones sake. Don't make it profitable for malicious agents to run these attacks. [0]: https://www.reddit.com/r/javascript/comments/7ob6a2/spectre_and_meltdown_exploit_javascript_example/ https://www.reddit.com/r/javascript/comments/7ob6a2/spectre_...
  - jotm 7y ago
    Ha, I had the same thought, comparing this to antivaxxers. The downsides are of course, infinitely lower (stolen password vs disability or death), but yeah the similarity is there. We've yet to see a real world attack using any of these, however.
  - scandinavian 7y ago
    From the comment in your link: > It's missing the entire actual implementation of the Spectre attack, which requires analysis of read times to see if you're hitting the processor cache or not. "analysis of read times" is what the browsers "fixed" to mitigate the attacks (and site isolation later). Again, there has been no working attacks on updated browsers. Please feel free to link an example of one though, I will gladly admit I'm wrong. You just seem to frankly have no idea how the exploits actually work though (did you actually read the code in the reddit post?), so I suspect that this conversation will be a waste of time.
    - dijit 7y ago
      The browser mitigation’s only work with the kernel mitigation’s. Neither is working well without the other. And yes. I’m very well versed on this topic.
      - scandinavian 7y ago
        >The browser mitigation’s only work with the kernel mitigation’s. That's just not true. The timer precision doesn't have anything to do with the kernel mitigations.
        dijit 7y ago
        The timing precision thing by itself doesn't twarte anything, it just makes the attacks harder or take more time. The browser vendors themselves said this; and it's not a permanent solution as tech such as Stadia and WebVR rely on high precision timers. But, whatever man, I'm telling you that it's stupid and you want to bury your head in the sand. You just make these attacks more likely; I'm not going to be impacted except for a few trillion CPU cycles of idiots trying to exploit me. You're the one who puts their entire digital life on the line by eking out 5% performance.
- Grangar 7y ago
  Browser 0-days still often run on user priviledges. The moment you get code-execution on a vulnerable Intel CPU that turns into hardware level access. And like the other commenter said, there are also JS implementations.
  - deleted 7y ago
    [deleted]
- MiroF 7y ago
  > There have been more Chrome/Firefox 0-days than speculative execution vulnerabilities exploitable in Javascript (0). sure dude, sure
  - scandinavian 7y ago
    Chrome: CVE-2019-13720, CVE-2019-5786 Firefox: CVE-2019-11707/CVE-2019-11708 Your turn. Link the speculative execution 0days.
    - MiroF 7y ago
      Here's an example of post-mitigation reading of protected memory using Javascript and Spectre https://alephsecurity.com/2018/06/26/spectre-browser-query-cache/ https://alephsecurity.com/2018/06/26/spectre-browser-query-c... I think it's just silly that you would rely on browser mitigations like disabling high precision timers when that's obviously just a hack.
      - scandinavian 7y ago
        As is said in the PoC, it does not bypass index masking and site-isolation. They read data already available to the code they are executing. They did show that the timer resolution mitigation is not 100% effective, which is well known and why it is not the only mitigation. That's not a speculative execution browser 0day, as it doesn't work in updated browsers and it never has (or I guess it works if you want to leak data you could just console.log). Could you post an actual 0day instead?
nullc 7y ago
Not every computer runs a web browser. Of the hundreds of high performance cores I have, only a couple run a web browser. ... thought increasingly more of them are non-intel.
- gpm 7y ago
  What about a network stack? Are they running one of those exposed to adversaries? http://www.misc0110.net/web/files/netspectre.pdf http://www.misc0110.net/web/files/netspectre.pdf
  - nullc 7y ago
    Very interesting link! but indeed, I have a lot of cores that are just on a private network.

coldtea 7y ago

>No I don't give a fuck about the 'risk' this introduces Well, let's hope you're not powned because of this and get dragged into giving some fucks, for a 5-10% of performance hit you wouldn't notice anyway...

systemcluster 7y ago
Anecdotally, the performance hit from the security mitigations since the Spectre/Meltdown publication has been very noticeable.
- ageofwant 7y ago
  More anecdata: On my workloads, which involves moving large discrete image frames as part of a video inference ML pipeline through a message broker and other processing pipelines, de-mitigating decreased system loads ~25% on average. Some workloads up to 30% depending on inference model. So yes noticeable.
ageofwant 7y ago
Pray, why do you think I would expend the effort of deliberately increasing my 'exposure' if I did not notice the effects of these mitigation on my workloads ? And they are not particularly unique. Do you understand my risk and load requirements better than I do ? Have you entertained the possibility that the decision to de-mitigate was the result of considered risk and resource management modeling ? But thanks for your concern and all.
- coldtea 7y ago
  >Pray, why do you think I would expend the effort of deliberately increasing my 'exposure' if I did not notice the effects of these mitigation on my workloads ? You'd be surprised what people would do. Could be just out of some spite ("fuck Intel"). Could not even include any measurable workloads ("I want my machine to go ultra fast"). >Do you understand my risk and load requirements better than I do ? For you particularly probably not, but you'd be surprised how many times a third party can "understand the risk and load requirements" of someone else (even a business) better than they do. E.g. the "No, you don't need a Hadoop cluster for doing "ML" on a 1GB file", phenomenon. >Have you entertained the possibility that the decision to de-mitigate was the result of considered risk and resource management modeling ? Only briefly, cause the tone of the comment made it sound more of a knee jerk reaction ("No I don't give a fuck about the 'risk' this introduces", "until everything is swapped to AMD") doesn't sound like the fruits of rational analysis...

uwydr 7y ago

You can do the same thing on Windows by using InSpectre: https://www.grc.com/inspectre.htm https://www.grc.com/inspectre.htm

yrro 7y ago

FYI, you can do the same thing with drop-in config files and avoid the annoying dpkg-conffile prompt whenever you upgrade grub2-common: $ cat /etc/default/grub.d/mitigations.cfg GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT mitigations=auto,nosmt"