4 ms·
Based on the fact that kernel patches are going in it's reasonable to assume this means it can't be fixed with a microcode update. Otherwise, Intel would issue
by daenney 9y ago
Based on the fact that kernel patches are going in it's reasonable to assume this means it can't be fixed with a microcode update. Otherwise, Intel would issue a microcode update and the Linux kernel wouldn't be accepting this patch set as a mitigation for this issue (which is all this patch set is, it has no other benefit to the end user than fixing this bug).
- zimmerfrei 9y agoIt depends on how long it takes for Intel to go through all regression tests for all affected platforms. If it takes several months to complete, a countermeasure in the kernel update may still be the better stopgap. Or maybe it could be that Intel privately disclosed already that no backport will be done to firmware of older CPUs, in which case the kernel update is the stopgap for newer generation and the solution for older generations.
- dx034 9y agoThey knew of the issue since June. Now that the patches are out it'll be hard to regain the performance. I doubt they are able to issue a microcode update within the following months. Otherwise large clients such as AWS would have implemented that instead.
- rurban 9y agoI wouldn't be so sure about that. Linus and Gross might think that it could be microcode fixable, because they wanted it configurable. Opt-out. However in the current patchset it's mandatory. With a future os-specific microcode patch a config option would make more sense. They just need to find a 2nd C3 register to seperate user from kernel space or do the permission check before prefetches. Like AMD does. On Linux this check would be cheap, on Windows NT not.