Avoid speculative indirect calls in kernel

Looking at the patches Linus is commenting on: as an Asm programmer, this is absolutely horrible --- basically every indirect call (one instruction) turns into a <i>seven</i>-instruction sequence that will, due to preventing speculation, result in massive slowdowns:<p><a href="https:&#x2F;&#x2F;lkml.org&#x2F;lkml&#x2F;2018&#x2F;1&#x2F;3&#x2F;770" rel="nofollow">https:&#x2F;&#x2F;lkml.org&#x2F;lkml&#x2F;2018&#x2F;1&#x2F;3&#x2F;770</a><p>Unlike the KPTI patches, which only affect things on each system call, this happens <i>on every indirect call</i> and probably bloats the code considerably too. I can see why Linus is not happy.<p>Edit: To give a bit more background, predicting indirect calls and speculating into them is absolutely critical to getting good performance from OOP-ish code which tends to use them a lot (virtual functions in C++, function pointers in C). The Linux kernel is (thankfully?) not very OOP-ish, but it does rely on indirect calls (function pointers) extensively.

This is my understanding, please correct me if wrong:<p>There&#x27;s a basic class of bugs (let&#x27;s call it Spectre-class) that&#x27;s about exfiltration of memory contents via side channels introduced by speculative execution. Basically every processor that can speculatively execute code (i.e., every modern one in the past two decades or so) is potentially vulnerable.<p>Of known Spectre-class bugs, one (Spectre) relies on branch predictor tables. All tested CPUs (ARM, AMD, Intel) were vulnerable to Spectre. The other bug publicly announced (Meltdown) relies on when the #GP(0) exception actually gets thrown and is specific to Intel CPUs. The fix for Spectre is to basically banish branch prediction, and the fix for Meltdown to is to unmap kernel pages when in userspace code.<p>Beyond these two bugs, there may exist other Spectre-class bugs specific to different architectures&#x2F;vendors that are not yet thoroughly investigated.<p>What did I get right and wrong?

Considering Intel is working on this for the last 6 months, it is indeed a little telling that they did not have the patch behind a feature flag. It also explains why AMD was so passive aggressive while inserting the exception for their CPUs. Seems like Intel was trying to make this some sort of act of god type of deal instead of writing out the if(intel){horrible mitigation}.

Well said and I think Linus was especially well restrained or perhaps &#x27;careful&#x27; with his wording here.

So is there no way to disable the performance crippling fix? If you ran an air gapped or highly controlled environment wouldn’t you want th option of disabling this to keep performance? How many Giga Terra or Exo FLops will be lost to this fix in super computers? Or is the way to disable it just not merge this patch into your custom kernel code?

Love it, an LFENCE on every indirect jump in core 32&#x2F;64bit entry assembler code, not to mention the cost of the trampoline itself. Linus is right to say that this hack should be reserved for configured as broken CPUs..

Linus missed the bus. The Spectre attack doesn&#x27;t require speculation across protection domains.

Why does he mention ARM64 instead of AMD?

My favorite is espfix. espfix64 is worse than espfix32 too. I have suggested limiting modify_ldt to root instead.

Does this disable the branch predictor for all function calls?

Very reserved for Linus :)

Somebody needs to tell him that the plural of CPU is &quot;CPUs&quot;, not &quot;CPU&#x27;s&quot; :-). I am afraid that even more people will start overusing apostrophes.

This seems unnecessary hostile. It&#x27;s quite obvious that these patches had to be completed in a hurry, and in addition to any number of similar patches for other systems. Configurability is currently useless for Intel CPUs, as all of them seem to be affected.<p>Depending on how their CPU development pipeline works, it&#x27;s quite likely that even the next generation will still be affected, giving everyone plenty of time later for such niceties.<p>It&#x27;s also slightly too harsh to call all of Intel&#x27;s work &quot;crap&quot; when this bug has apparently existed for the better part of two decades without being noticed.

This would be more convincing if the x86 CPU manufacturer he used to work for were still in business.<p>I mean, I could sit here and criticize how Linus runs his kernel development project and how so much insecure code gets in, and talk about what a &quot;competent&quot; kernel developer would do, but since I don&#x27;t run an equally successful, more secure kernel, it&#x27;s just armchair quarterbacking.