5 ms·

> I thought that the fix even on 7th and 8th generations had a low overhead. One of the fixes slow down kernel syscalls by a significant amount. So much so tha

by bkor 9y ago

> I thought that the fix even on 7th and 8th generations had a low overhead. One of the fixes slow down kernel syscalls by a significant amount. So much so that your IO will be heavily affected. Intel is mostly responding is dishonest ways, e.g. showing the impact on CPU-only benchmarks. The current patches do have a significant impact! What someone else explained here is that due to the heavy impact, it seems Intel isn't planning to fix it in future CPU's. Basically a "if you are super security minded enable that special slow secure mode Linux has where they slow down your performance". Meaning, blame Linux/your requirements not Intel.

cm2187 9y ago
To be honest, unless there is a better solution (and I don't think I heard anyone suggesting that Intel could have mitigated it in some other way in older chips), I think it makes sense to make the fix optional. The vulnerability as I understand it doesn't affect everyone in the same way. Save for the javascript vector which can be easily mitigated (and will be), most consumers and single tenant servers aren't really affected (if you have rogue code executing in user mode, access to kernel memory is the least of your worries, it will have encrypted your data and made your device a spam or DDOS bot before). The risk is really in a large organisation where you need to be resilient to one machine going bad, and in a multi-tenant infrastructure (cloud / hosting providers). I don't really get the blame game that seems to be at stake here.
- Kalium 9y ago
  What some have offered up as the ideal approach is to make the fix optional, but default to on. There might be some level of concern for the consequences of adding to the patch-maintenance load of technical organizations. Already, IT groups and application maintainers cannot always be fully relied upon to have their machine fleets and libraries up to date. It's also possible that an unpatched machine might suffer from some risk in the form of a significant privilege escalation vulnerability here. Some might opine that any such vulnerability should be closed off wherever possible, as there may be other threats than cryptolockers or botnetting.

by bkor 9y ago

cm2187 9y ago

To be honest, unless there is a better solution (and I don't think I heard anyone suggesting that Intel could have mitigated it in some other way in older chips), I think it makes sense to make the fix optional. The vulnerability as I understand it doesn't affect everyone in the same way. Save for the javascript vector which can be easily mitigated (and will be), most consumers and single tenant servers aren't really affected (if you have rogue code executing in user mode, access to kernel memory is the least of your worries, it will have encrypted your data and made your device a spam or DDOS bot before). The risk is really in a large organisation where you need to be resilient to one machine going bad, and in a multi-tenant infrastructure (cloud / hosting providers). I don't really get the blame game that seems to be at stake here.

Kalium 9y ago
What some have offered up as the ideal approach is to make the fix optional, but default to on. There might be some level of concern for the consequences of adding to the patch-maintenance load of technical organizations. Already, IT groups and application maintainers cannot always be fully relied upon to have their machine fleets and libraries up to date. It's also possible that an unpatched machine might suffer from some risk in the form of a significant privilege escalation vulnerability here. Some might opine that any such vulnerability should be closed off wherever possible, as there may be other threats than cryptolockers or botnetting.