https://lwn.net/Articles/742404/ et autres: les détails ne sont pas publics pour l'instant, mais il y a apparemment un gros problème de sécurité dans les processeurs x86_64 d'Intel (au moins)...
En tout cas, suffisant pour qu'un contournement soit mis en place, en hâte, dans un build de Windows 10 en novembre, et maintenant dans Linux. Malheureusement, ledit contournement, baptisé KPTI dans Linux, a un coût terrible en performance: d'après le flux https://twitter.com/grsecurity, un simple `du -s` cache chaud devient plus lent de 34% sur un Ivy Bridge, 29% pour un Skylake et 49% sur un EPYC (qui ne semblerait pas affecté par ce problème-là et n'aurait pas besoin de KPTI, mais https://lkml.org/lkml/2017/12/27/2 ne fait pas encore partie de mainline)...

KPTI n'améliore pas l'insécurité habituelle du kernel Linux - il reste toujours possible, voire facile, de contourner KASLR grâce aux nombreux infoleaks, exécuter directement du code user-space en mode kernel sur les nombreux processeurs qui n'ont pas de protection matérielle, de déréférencer trop directement des données en user-space sur les nombreux processeurs qui n'ont pas de protection matérielle, de faire du ROP à cause de l'absence d'intégrité de flux de contrôle à l'exécution, etc.

Le feed de spender relaie aussi le fait qu'Azure propose maintenant une mise à jour de sécurité nécessitant le reboot des VMs, et plus tôt, le fait que des adresses @amazon.com et @google.com soient en Cc des patches; les principaux hébergeurs cloud public sont donc affectés à l'échelle immense qui est la leur, et ils ont manifestement intérêt à patcher au plus tôt, comme les autres.