4 ms·

I don't completely understand the technical issues, but reading between the lines I think the patches in question add super huge overhead. The overhead is so h

I don't completely understand the technical issues, but reading between the lines I think the patches in question add super huge overhead. The overhead is so huge that nobody in their right mind would enable them by choice. However, the behaviour is governed by an opt-in configuration at boot time. What this means is that by default the patches will do nothing but if you opt in, you will get a huge performance hit. The end result is that Intel can say, "We've fixed the security holes". Linus can apply the patches and say, "I've fixed the security hole". However no distribution will enable it because they will suffer from a massive performance penalty if they do. The end result is that the security hole will remain, but the average person/manager/etc will not be aware of it. As far as I can tell Linus is calling that out as being complete BS. From what I can tell, his reasoning is that if there needs to be a performance hit, then Intel can eat it. They will have to get their act together and fix the problem in upcoming processors or else basically nobody will buy them. The implication is that Intel has no intention of fixing the problem in the next generation of processors and is hoping to sweep it all under the rug -- they have a fix. It's not their fault if nobody enables it. The situation is a bit delicate because if Linus forces the Intel processors to be slow, then Intel will blame him -- their patches are only slow if you opt in to some completely-not-understandable-kernel-patch-option. He's basically refusing to play ball at all -- which is probably the correct stance (assuming I understand what's going on -- insert disclaimer about being a random person from the internet here). I don't think Linus is necessarily blaming anyone in particular. That's why he says the reasons behind the patches are unclear. I think he's hoping that causing bad publicity will get Intel to abandon their tactic of being politically careful. Getting slagged of by Linus carries a certain stigma and Intel may consider it prudent to offer up information more quickly in order to stem the damage.

bencollier49 9y ago
Particularly interesting; the opt-in creates an incentive for OS vendors to comply, as being the only platform to go all-in would create an impression to the end user of poorer performance using your product.
cm2187 9y ago
But are we talking about fixing it on current chips or future chips? If the former I understand Linus’ position only if there is a better solution. But if it is a hardware problem it may not. If we are talking about future chips, I thought that the fix even on 7th and 8th generations had a low overhead. Why would it have a bigger overhead in future designs?
- 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.

bencollier49 9y ago

Particularly interesting; the opt-in creates an incentive for OS vendors to comply, as being the only platform to go all-in would create an impression to the end user of poorer performance using your product.

cm2187 9y ago

But are we talking about fixing it on current chips or future chips? If the former I understand Linus’ position only if there is a better solution. But if it is a hardware problem it may not. If we are talking about future chips, I thought that the fix even on 7th and 8th generations had a low overhead. Why would it have a bigger overhead in future designs?

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.