3 ms·

> Anyway, Meltdown is only fixable by an os update (that software patch which causes the massive 5-20%). Yes, currently the OS update with the performance degr

by jo909 9y ago

> Anyway, Meltdown is only fixable by an os update (that software patch which causes the massive 5-20%). Yes, currently the OS update with the performance degradation is all we have. But could there be other future solutions that work differently and thus have lower performance impacts? I think there could be. AMD is not affected, so it is not at all impossible to have a CPU behave "correctly". Wether Intel is able to correct their behavior only in microcode is of course a different question, that I'm not really able to judge. But it could still be possible for them to add special CPU instructions that allow the kernel to explicitly protect it's address space and go back to the previous memory mapping. I'm not super hopeful since they already had a lot of time to look into that and did not come out or announce such a solution, but maybe they deferred that in the light that KPTI works and is "good enough" for a first mitigation.

xenadu02 9y ago
My understanding is that the latest AMD CPUs use a neural net branch predictor which requires that they store the entire address, not just some of the bits, so you can’t effectively poison the branch predictor. Everyone else will switch to the same model. I suspect that cache changes will need to be tagged with the reorder buffer slot and rolled-back on mis-predict. It also means a hit to the N-way scheme because you must be able to hold multiple instances of the cache line for the same address. I also worry there are undiscovered side channels lurking in arch-specific registers or status bits.
- phire 9y ago
  Rolling back the cache changes is just asking for trouble. Consider that any cycles you spend undoing cache changes is also a side effect that can potentially be measured. Instead, hold the newly loaded cache lines in a "cache line buffer", the same way how stores are held in a store buffer. For any reads, the CPU will check the cache load buffers before L1 cache. Then once the instruction which triggered the cache read completes, the new cache line will finally be applied to the L1 cache and the old line evicted. In the case of a misprediction, the cache load buffers can be discarded instantly.
phire 9y ago
I'm willing to bet that it's impossible to fix meltdown with microcode, because the bug is not in a microcoded part of the CPU. In the future, we might see OS optimisations that work around the slowdowns by doing even less syscalls, but KPTI will stay until meltdown is fixed in silicon (which won't happen for 2-4 years)

by jo909 9y ago

xenadu02 9y ago

My understanding is that the latest AMD CPUs use a neural net branch predictor which requires that they store the entire address, not just some of the bits, so you can’t effectively poison the branch predictor. Everyone else will switch to the same model. I suspect that cache changes will need to be tagged with the reorder buffer slot and rolled-back on mis-predict. It also means a hit to the N-way scheme because you must be able to hold multiple instances of the cache line for the same address. I also worry there are undiscovered side channels lurking in arch-specific registers or status bits.

phire 9y ago
Rolling back the cache changes is just asking for trouble. Consider that any cycles you spend undoing cache changes is also a side effect that can potentially be measured. Instead, hold the newly loaded cache lines in a "cache line buffer", the same way how stores are held in a store buffer. For any reads, the CPU will check the cache load buffers before L1 cache. Then once the instruction which triggered the cache read completes, the new cache line will finally be applied to the L1 cache and the old line evicted. In the case of a misprediction, the cache load buffers can be discarded instantly.

phire 9y ago

I'm willing to bet that it's impossible to fix meltdown with microcode, because the bug is not in a microcoded part of the CPU. In the future, we might see OS optimisations that work around the slowdowns by doing even less syscalls, but KPTI will stay until meltdown is fixed in silicon (which won't happen for 2-4 years)