3 ms·
You can read the original conversation from 2018 here: https://lkml.org/lkml/2018/1/21/192 https://lkml.org/lkml/2018/1/21/192
by plam503711 4y ago
You can read the original conversation from 2018 here: https://lkml.org/lkml/2018/1/21/192 https://lkml.org/lkml/2018/1/21/192
- Sakos 4y agoPrevious discussion (2018): https://news.ycombinator.com/item?id=16202205 https://news.ycombinator.com/item?id=16202205 I get the sense that IBRS wasn't used because Linus 1) didn't want to take on the responsibility of fixing something that needs to be fixed in hardware by Intel and 2) didn't want to help Intel avoid responsibility for shipping insecure hardware. The same way he's been antagonistic towards nVidia for being bad participants.
- generalizations 4y agoSounds like Linux/Linus figured they had enough clout to call bs on the patch, while Xen just focused on doing the best with what they had. I honestly don't blame either.
- nousermane 4y ago> Linus (...) didn't want to help Intel avoid responsibility for shipping insecure hardware. Whatever is the saying about good intentions, you can argue he ended up doing Intel a favour here, by shipping patch that took away only a couple % of performance. Surely, it would've hurt them more, reputation-wise, if default workaround took larger chunk of CPU speed.
- Sakos 4y agoPossibly. It also seems like the changes would've added an amount of technical debt that wasn't acceptable to him ("garbage MSR writes" in and out of the kernel). I could understand why he'd want to avoid a bad solution (that would also have to be maintained long-term) just because Intel is unwilling to fix it on their end.