5 ms·

The problem is that every fix that you could think for Spectre reduces the performance of the CPU. So not enabling this by default it's a good choice, Spectre

The problem is that every fix that you could think for Spectre reduces the performance of the CPU. So not enabling this by default it's a good choice, Spectre is very difficult to exploit: so if you do critical things you enable the fix, if you use the computer for gaming, video rendering, and things where you don't care too much about security but you care about performance, you don't enable it.

eeeficus 9y ago
Why not the other way around? You have the fix enabled and if you don't know you get protected by default. If you really know better then you can disable the fix (via a special CPU instruction), because you know you're not running anything critical?
- draugadrotten 9y ago
  > you can disable the fix (via a special CPU instruction) The CPU can not be allowed to disable the fix, because then that could be done by an attacker. Therefore the only more secure way is to move in the secure direction, from insecure to more secure.
  - simias 9y ago
    Nonsense, just make it so that only privileged kernel code can modify this configuration. Tons of CPU configuration parameters already work that way, it's a non-issue. If for some reason you even want to forbid even privileged code from modifying the config then add an other "lock" bit that forbids subsequent reconfiguration till the next reboot.
  - nolok 9y ago
    Uh no, they would obviously make it so only kernel code can run that, like many other such settings. And if an attacker can run code at the kernel level it's a non issue, as they're already on the other side of the airtight hatchway anyway [1]: they're in control of the computer and the memory. [1]: https://blogs.msdn.microsoft.com/oldnewthing/20060508-22/?p=31283 https://blogs.msdn.microsoft.com/oldnewthing/20060508-22/?p=...
JohnStrange 9y ago
Insecure defaults are always bad. The other way round would be the right choice. Let users downgrade their security for performance, if they insist.
IntelMiner 9y ago
"Spectre is very difficult to exploit" From what I've seen. There's been demonstrated attacks using Javascript in Chrome to dump the saved passwords from the browser using these bugs If an attack is that easy to pull off, I don't think it's reasonable to make it an "opt in"
- syncsynchalt 9y ago
  Agreed, I keep hearing it's difficult yet user om2 on the webkit team says they were able to come up with multiple attacks internally in the webkit team once they'd heard about the trick [1]. Safari/webkit have since rolled out mitigations to prevent the attacks that they figured out but it puts the lie to the idea that Spectre is only a theoretical attack that we've yet to see an exploit for. [1] https://news.ycombinator.com/item?id=16104831 https://news.ycombinator.com/item?id=16104831
crpatino 9y ago
Sorry, but no. That's very much NOT how you want to think about security. And because that's how most executives, technical leaders and managers think, we ended up in this shit storm in the first place. Given how integrated is IT with everybodie's financial information, and now with the Internet of Things with automatic devices that have real effects in the physical world, you must enable secure defaults for everything. Only on devices whose purpose is 100% entertainment, like smart TVs (and then, you cannot trust that assumption either because everything is connected to everything, but I digress) you may set unsecure defaults. What we need is a secure default, and a way to enable usafe features, on a per process basis if possible. That way, you can delegate the decision of what level of security is required for the application developers. Other than that, you need to educate the public to pick Safe!Device vs Fast!Device, which goes very much against the common wisdom dujour.

eeeficus 9y ago

Why not the other way around? You have the fix enabled and if you don't know you get protected by default. If you really know better then you can disable the fix (via a special CPU instruction), because you know you're not running anything critical?

draugadrotten 9y ago
> you can disable the fix (via a special CPU instruction) The CPU can not be allowed to disable the fix, because then that could be done by an attacker. Therefore the only more secure way is to move in the secure direction, from insecure to more secure.
- simias 9y ago
  Nonsense, just make it so that only privileged kernel code can modify this configuration. Tons of CPU configuration parameters already work that way, it's a non-issue. If for some reason you even want to forbid even privileged code from modifying the config then add an other "lock" bit that forbids subsequent reconfiguration till the next reboot.
- nolok 9y ago
  Uh no, they would obviously make it so only kernel code can run that, like many other such settings. And if an attacker can run code at the kernel level it's a non issue, as they're already on the other side of the airtight hatchway anyway [1]: they're in control of the computer and the memory. [1]: https://blogs.msdn.microsoft.com/oldnewthing/20060508-22/?p=31283 https://blogs.msdn.microsoft.com/oldnewthing/20060508-22/?p=...

JohnStrange 9y ago

Insecure defaults are always bad. The other way round would be the right choice. Let users downgrade their security for performance, if they insist.

IntelMiner 9y ago

"Spectre is very difficult to exploit" From what I've seen. There's been demonstrated attacks using Javascript in Chrome to dump the saved passwords from the browser using these bugs If an attack is that easy to pull off, I don't think it's reasonable to make it an "opt in"

syncsynchalt 9y ago
Agreed, I keep hearing it's difficult yet user om2 on the webkit team says they were able to come up with multiple attacks internally in the webkit team once they'd heard about the trick [1]. Safari/webkit have since rolled out mitigations to prevent the attacks that they figured out but it puts the lie to the idea that Spectre is only a theoretical attack that we've yet to see an exploit for. [1] https://news.ycombinator.com/item?id=16104831 https://news.ycombinator.com/item?id=16104831

crpatino 9y ago

Sorry, but no. That's very much NOT how you want to think about security. And because that's how most executives, technical leaders and managers think, we ended up in this shit storm in the first place. Given how integrated is IT with everybodie's financial information, and now with the Internet of Things with automatic devices that have real effects in the physical world, you must enable secure defaults for everything. Only on devices whose purpose is 100% entertainment, like smart TVs (and then, you cannot trust that assumption either because everything is connected to everything, but I digress) you may set unsecure defaults. What we need is a secure default, and a way to enable usafe features, on a per process basis if possible. That way, you can delegate the decision of what level of security is required for the application developers. Other than that, you need to educate the public to pick Safe!Device vs Fast!Device, which goes very much against the common wisdom dujour.