OSDev.org

what about this code ? I have definately seen smth about this about 4 years ago on an assembly forum.

I believe cmovCC doesn't pair with anything really, but what about condition predition - i don't know.

The nice thing about retpoline (the code I posted earlier) is that lfence is not actually executed. It is only executed speculatively and thus the cost of retpoline is just the cost of two static branches, which is much lower than the cost of a real barrier.

thanks Korona

Has anyone done testing on performance?

My queue was running at 17.6 million per second per core.
To get around the hardware issue I set cr3 on a system call, to make the kernel pages visible.
Then before returning back to userspace I had to set cr3 again to hide kernel pages.
My queue dropped to 2.2 million.
This is a drop of over 80%

The next step is to test with Page Present, then CPID

Anyone else have some results?

Ali

If I understand the issue correctly it is TLB entries that is the issue and thus it is the reading of a kernel address from userspace speculatively that leaves the address in the TLB even if it is not allowed. Thus, a 32 bit operating system that has usermode selectors that don't allow access to kernel space will not be vulnerable to these exploits. Which means I don't need any fixes for this at all.

The issue (for Meltdown) is that those selector CPL vs. PTE checks were not done during speculative execution. I don't know if anyone tested whether segment limit checks are done during speculative execution. So unless that's tested, it's not clear whether segmentation can mitigate the issue or not. (If you test it, feel free to post the results here, would be interesting to know.)

Korona wrote:The issue (for Meltdown) is that those selector CPL vs. PTE checks were not done during speculative execution. I don't know if anyone tested whether segment limit checks are done during speculative execution. So unless that's tested, it's not clear whether segmentation can mitigate the issue or not. (If you test it, feel free to post the results here, would be interesting to know.)

I'm not sure how to do that. Intel processors had penalties for not using 4G flat selectors which related to adding the base to form a linear address, which indicates that segmentation checks cannot be skipped with speculative execution. My guess is that Intel would only skjp those checks if 4G flat selectors are used, which both Windows and Linux use.

Korona wrote:The issue (for Meltdown) is that those selector CPL vs. PTE checks were not done during speculative execution. I don't know if anyone tested whether segment limit checks are done during speculative execution. So unless that's tested, it's not clear whether segmentation can mitigate the issue or not. (If you test it, feel free to post the results here, would be interesting to know.)

Meltdown is that these checks, which do happen on all CPUs (and which would be a huge bug if they didn't!), happened on the speculative path only to trigger the error if that case was actually executed. They were not used to determine whether to speculate further. That meant that you could leak the data loaded with the invalid load through a side-channel if you have one.

This is a 'simple' thing to fix - just stop speculative execution if an error has occurred. Not easy to retrofit, but easy enough for new machines, and of course AMD and other AMD64/X86_64 vendors don't have this problem because they didn't make that mistake to start with.

Spectre is much harder as it revolves around mistraining a BPB, BTB or similar structure to cause a wrong branch to be taken with sensitive data on another process, which the wrong branch then leaks through a side channel. Harder to abuse, but just about impossible to fix.

Retpoline locally disables the BTB. So you can't poison the BTB any more effectively, because it doesn't use it any more.