8 ms·

You absolutely need Spectre/Meltdown mitigation otherwise someone could attack you with JavaScript running in your web browser. https://linuxreviews.org/HOWTO_

You absolutely need Spectre/Meltdown mitigation otherwise someone could attack you with JavaScript running in your web browser. https://linuxreviews.org/HOWTO_make_Linux_run_blazing_fast_(again)_on_Intel_CPUs https://linuxreviews.org/HOWTO_make_Linux_run_blazing_fast_(... noibrs - We don't need no restricted indirect branch speculation noibpb - We don't need no indirect branch prediction barrier either nospectre_v1 and nospectre_v2: Don't care if some program can get data from some other program when it shouldn't l1tf=off - Why would we be flushing the L1 cache, we might need that data. So what if anyone can get at it. nospec_store_bypass_disable - Of course we want to use, not bypass, the stored data no_stf_barrier - We don't need no barriers between software, they could be friends mds=off - Zombieload attacks are fine mitigations=off - Of course we don't want no mitigations

seminatl 7y ago
You just leaped to the unfounded conclusion that every computer needs to run untrusted JavaScript. The vast majority of computers have no such need. Especially in a performance-sensitive contest like buying CPU for your database server that lives in a datacenter and never runs a web browser you will certainly disable these security things.
- computerex 7y ago
  Disabling Spectre/Meltdown mitigations on a server especially would be the dumbest thing imaginable. These attacks are not restricted to JavaScript, they are side-channel attacks and have a huge exploitable surface. Just look at the number of patches for the MS SQL server needed to mitigate: https://support.microsoft.com/en-us/help/4073225/guidance-protect-sql-server-against-spectre-meltdown https://support.microsoft.com/en-us/help/4073225/guidance-pr...
  - reacharavindh 7y ago
    No, it is NOT the dumbest thing imaginable! If your server is not reachable from untrusted sources, and you are running only what you trust, it is prudent to disable mitigation’s and make use of the extra performance. Example, I run many compute nodes (only private network) in my HPC cluster with mitigation’s off. If an attacker could reach the compute nodes over the network to push the attack payload, I’ve already been heavily compromised that these attacks are just insult to the injury. If you run a database server that can never be reached directly by an attacker. You may spend your time watching your application server and let the DB server use the extra oomph.
    - Darkphibre 7y ago
      That's a fascinating take on internal security. Naturally, everyone must determine their level of risk aversion and take the steps they feel most prudent. I've not heard this perspective before. Thank you for sharing!
      - loeg 7y ago
        It's basically the historical approach to enterprise security: secure the perimeter, and don't worry about the intranet. It's still hugely popular in enterprise IT. Cryptolocker/Wannacry bit these IT departments hard and they've sort of slowly learned some lessons, but there's huge inertia, low budget, and these things are changing glacially.
        dvfjsdhgfv 7y ago
        No, I think you're mixing things up, these two are two distinct things: 1) the old "M&M" approach of securing just the perimeter is basically asking for trouble, but 2) doing proper risk assessment and choosing performance over security for one particular setup.
  - pvg 7y ago
    Scroll down to the table and many paragraphs in which they describe when the various scenarios in which the various mitigations are recommended. That wouldn't be needed at all if not having them was always 'the dumbest thing imaginable'.
    - computerex 7y ago
      Can you point out where Microsoft recommends that you do nothing besides if the user is using "Azure SQL Database and Data Warehouse" (and that's because mitigations are already deployed on their cloud services)? Microsoft has deployed mitigations across all our cloud services. https://docs.microsoft.com/en-us/azure/virtual-machines/windows/mitigate-se https://docs.microsoft.com/en-us/azure/virtual-machines/wind...
  - retrovm 7y ago
    If your threat model is "all the threats all the time" then I assume you also wear a helmet when walking down the street.
- CJefferson 7y ago
  I would think the "vast majority" of computers are used interactively by people using Web browsers. Surely the number of servers in the world doesn't massively outnumber clients, and most of the clients browse the Web?
- spamizbad 7y ago
  The only applications that will disable these mitigations are maybe home power users or certain niches where access to the system is always trusted. For everyone else, there's performance stealing mitigations. If you or your employer doesn't apply mitigations I certainly wouldn't go around bragging about it. Let it be a deep, dark secret until the next hw upgrade cycle. Otherwise you'll get pilloried and/or sued for any data breach.
- loeg 7y ago
  > You just leaped to the unfounded conclusion that every computer needs to run untrusted JavaScript. You're right about that... > The vast majority of computers have no such need. You're probably wrong about that. Every, no. Majority or substantial minority? Yes. There are a ton of consumer computer devices that act as web browsers, and smartphones absolutely count here.
pkaye 7y ago
Is there a working JavaScript exploit for Spectre/Meltdown? I though it was just hypothetical.
- deaddodo 7y ago
  There was a proof-of-concept included in the whitepaper: https://spectreattack.com/spectre.pdf https://spectreattack.com/spectre.pdf That's a working exploit, not a hypothetical.
  - icedchai 7y ago
    A proof-of-concept is not a real world exploit. The PoC operates under perfect conditions.
  - scandinavian 7y ago
    No, that's not a working exploit, as is said in the paper: > Chrome intentionally degrades the accuracy of its high-resolution timer to dissuade timing attacks using performance.now() [62]. However, the Web Workers feature of HTML5 makes it simple to create a separate thread that repeatedly decrements a value in a shared memory location [24, 60]. This approach yields a high-resolution timer that provides sufficient resolution. They did it on Chrome 62.0.3202, but SharedArrayBuffer was disabled in all major browsers right when spectre dropped. Chrome enabled it again in Chrome 67 if Full Site Isolation was enabled. Full site isolation is now enabled by default afaik. So no, that is in no way a working exploit in any major browser I know of. There is no know spectre (or other variant) exploit that works in a default updated major browser (and there has never been as far as I know), but feel free to link any PoC's.
    - deaddodo 7y ago
      You're right. When the white paper was announced; it was pre-released to specific entities to work around. The fact that the exploits have since been patched doesn't remove the fact that they were a valid exploit. Was heartbleed not an exploit because it's since been patched? Or the thousands of DOS TSR viruses? What is even your point or logic here?
robocat 7y ago
> You absolutely need Spectre/Meltdown mitigation The article context is HPC - it seems very unlikely Spectre/Meltdown fixes are needed for HPC loads (no browser, no VM sharing).
- sliken 7y ago
  Not only no VM sharing, but no VMs.

seminatl 7y ago

You just leaped to the unfounded conclusion that every computer needs to run untrusted JavaScript. The vast majority of computers have no such need. Especially in a performance-sensitive contest like buying CPU for your database server that lives in a datacenter and never runs a web browser you will certainly disable these security things.

computerex 7y ago
Disabling Spectre/Meltdown mitigations on a server especially would be the dumbest thing imaginable. These attacks are not restricted to JavaScript, they are side-channel attacks and have a huge exploitable surface. Just look at the number of patches for the MS SQL server needed to mitigate: https://support.microsoft.com/en-us/help/4073225/guidance-protect-sql-server-against-spectre-meltdown https://support.microsoft.com/en-us/help/4073225/guidance-pr...
- reacharavindh 7y ago
  No, it is NOT the dumbest thing imaginable! If your server is not reachable from untrusted sources, and you are running only what you trust, it is prudent to disable mitigation’s and make use of the extra performance. Example, I run many compute nodes (only private network) in my HPC cluster with mitigation’s off. If an attacker could reach the compute nodes over the network to push the attack payload, I’ve already been heavily compromised that these attacks are just insult to the injury. If you run a database server that can never be reached directly by an attacker. You may spend your time watching your application server and let the DB server use the extra oomph.
  - Darkphibre 7y ago
    That's a fascinating take on internal security. Naturally, everyone must determine their level of risk aversion and take the steps they feel most prudent. I've not heard this perspective before. Thank you for sharing!
    - loeg 7y ago
      It's basically the historical approach to enterprise security: secure the perimeter, and don't worry about the intranet. It's still hugely popular in enterprise IT. Cryptolocker/Wannacry bit these IT departments hard and they've sort of slowly learned some lessons, but there's huge inertia, low budget, and these things are changing glacially.
      - dvfjsdhgfv 7y ago
        No, I think you're mixing things up, these two are two distinct things: 1) the old "M&M" approach of securing just the perimeter is basically asking for trouble, but 2) doing proper risk assessment and choosing performance over security for one particular setup.
- pvg 7y ago
  Scroll down to the table and many paragraphs in which they describe when the various scenarios in which the various mitigations are recommended. That wouldn't be needed at all if not having them was always 'the dumbest thing imaginable'.
  - computerex 7y ago
    Can you point out where Microsoft recommends that you do nothing besides if the user is using "Azure SQL Database and Data Warehouse" (and that's because mitigations are already deployed on their cloud services)? Microsoft has deployed mitigations across all our cloud services. https://docs.microsoft.com/en-us/azure/virtual-machines/windows/mitigate-se https://docs.microsoft.com/en-us/azure/virtual-machines/wind...
- retrovm 7y ago
  If your threat model is "all the threats all the time" then I assume you also wear a helmet when walking down the street.
CJefferson 7y ago
I would think the "vast majority" of computers are used interactively by people using Web browsers. Surely the number of servers in the world doesn't massively outnumber clients, and most of the clients browse the Web?
spamizbad 7y ago
The only applications that will disable these mitigations are maybe home power users or certain niches where access to the system is always trusted. For everyone else, there's performance stealing mitigations. If you or your employer doesn't apply mitigations I certainly wouldn't go around bragging about it. Let it be a deep, dark secret until the next hw upgrade cycle. Otherwise you'll get pilloried and/or sued for any data breach.
loeg 7y ago
> You just leaped to the unfounded conclusion that every computer needs to run untrusted JavaScript. You're right about that... > The vast majority of computers have no such need. You're probably wrong about that. Every, no. Majority or substantial minority? Yes. There are a ton of consumer computer devices that act as web browsers, and smartphones absolutely count here.

pkaye 7y ago

Is there a working JavaScript exploit for Spectre/Meltdown? I though it was just hypothetical.

deaddodo 7y ago
There was a proof-of-concept included in the whitepaper: https://spectreattack.com/spectre.pdf https://spectreattack.com/spectre.pdf That's a working exploit, not a hypothetical.
- icedchai 7y ago
  A proof-of-concept is not a real world exploit. The PoC operates under perfect conditions.
- scandinavian 7y ago
  No, that's not a working exploit, as is said in the paper: > Chrome intentionally degrades the accuracy of its high-resolution timer to dissuade timing attacks using performance.now() [62]. However, the Web Workers feature of HTML5 makes it simple to create a separate thread that repeatedly decrements a value in a shared memory location [24, 60]. This approach yields a high-resolution timer that provides sufficient resolution. They did it on Chrome 62.0.3202, but SharedArrayBuffer was disabled in all major browsers right when spectre dropped. Chrome enabled it again in Chrome 67 if Full Site Isolation was enabled. Full site isolation is now enabled by default afaik. So no, that is in no way a working exploit in any major browser I know of. There is no know spectre (or other variant) exploit that works in a default updated major browser (and there has never been as far as I know), but feel free to link any PoC's.
  - deaddodo 7y ago
    You're right. When the white paper was announced; it was pre-released to specific entities to work around. The fact that the exploits have since been patched doesn't remove the fact that they were a valid exploit. Was heartbleed not an exploit because it's since been patched? Or the thousands of DOS TSR viruses? What is even your point or logic here?

robocat 7y ago

> You absolutely need Spectre/Meltdown mitigation The article context is HPC - it seems very unlikely Spectre/Meltdown fixes are needed for HPC loads (no browser, no VM sharing).

sliken 7y ago
Not only no VM sharing, but no VMs.