Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.



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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: