Yeah, intel has been continually misleading with their PR. By neglecting to mention the software updates, they are trying to trick people into thinking "oh there is a firmware/microcode update which fixes it".

Anyway, Meltdown is only fixable by an os update (that software patch which causes the massive 5-20%).

The microcode updates give os developers a few extra tools that allows them to build Spectre migrations, like temporarily disabling indirect branch detection while kernel code executes, or flushing the indirect branch entries on switch to kernel mode.

> 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.

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.

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.

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)

That's correct, and i assume these benchmarks are quite questionable, as to fix all the things require both software and firmware updates. as well as we are working with branch prediction, and such the benchmark affect this mostly. and furthermore it's very very program dependent.