6 ms·
Avoid speculative indirect calls in kernel
- qaq 9y agoVery reserved for Linus :)
- anfilt 9y agoIndeed. Although he did say: "... and that really means that all these mitigation patches should be written with "not all CPU's are crap" in mind."
- StavrosK 9y agoWhy does he mention ARM64 instead of AMD?
- hacknat 9y agoBecause Intel writes almost all of the x86 arch code for Linux, so AMD gets stuck footing the bill for hardware bugs like this, even if AMD isn’t affected. From Linus’s perspective it’s the same arch, because, well, it is.
- anfilt 9y agoWell he does say patches should written that don't treat all CPUs as crap. AMD had to basically say "Wait a moment! This does not affect our CPUs what are you doing Intel?"
- StavrosK 9y agoAs far as I understand, one of the two attacks does affect AMD, and it's hard to solve as it relies on normal branch prediction.
- anfilt 9y agoWell there is spectre, and meltdown. Spectre is much more limited than meltdown. The patch AMD was referring to was for Meltdown. Spectre at least does not leak ring-0 memory. Sure it means that some application might be able to read/infer memory values of other user-mode process.
- mintplant 9y agoSpectre is much scarier than Meltdown, from my understanding, because it represents a whole class of strategies that lack a single fix, even at the hardware level.
- earenndil 9y agoMy understanding is that it's not a bug of unintended behaviour, but rather a problem with the specification, all behaviour is as intended, but we need to have different behaviour. Which means that basically we need to get a new ISA -- or a new version of an existing one -- and transition everything to it.
- doikor 9y agoAmd claims that two of the three spectre attacks don't work on their hardware and the last one (variant one) is fixable with negligible performance impact. https://www.amd.com/en/corporate/speculative-execution https://www.amd.com/en/corporate/speculative-execution
- deleted 9y ago[deleted]
- voxadam 9y agoLinus has a long history with, a deep understanding of, and I presume a special place in his heart for x86 microarchitectures.
- maxxxxx 9y agoSomebody needs to tell him that the plural of CPU is "CPUs", not "CPU's" :-). I am afraid that even more people will start overusing apostrophes.
- anfilt 9y agoLet's try avoiding being pedants. Human language is quite squishy and imprecise anyways.
- hateduser2 9y agoAgreed. Whether or not you think grammar matters, bringing it up is destructive to the conversation this is meant to start.
- ewams 9y agoPretty common in our industry to use apostrophes after an acronym to make it plural. An example is VM's and VMS are two different things. When you get lazy and do vm's and vms you can not always be sure, I have even written an email where I stated "we need multiple VMS VM's".
- andrewflnr 9y agoUsing an apostrophe is the technically correct way to pluralize acronyms.
- dexwiz 9y agoSo 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?
- revelation 9y agoThis isn't the fix with the 5% quoted performance loss (that one clears all of TLB on every syscall), I don't think this is as costly. But it's certainly not free and it's certainly not clean. I'm disappointed Intel didn't bother to test the performance impact of this and report it in the patchset. Benchmarks are ordinarily expected with something like this (very hot paths they are changing), and they did have 6 months..
- userbinator 9y agoThis is worse, far worse --- it basically disables prediction for indirect jumps and calls, plus adds another few extra clock cycles to each one of those for the "retoline" instruction sequence.
- PhantomGremlin 9y agoI'm disappointed Intel didn't bother to test the performance impact of this and report it in the patchset. You should be disappointed that they didn't report it. But I'd be willing to bet every last dollar of my net worth that Intel has done very extensive performance testing. I'd venture that the results are far too embarrassing to report.
- barkingcat 9y agoYup this for sure. They probably ran the performance test bench thousands of times, and only then released it with the PR department fully briefed about how bad it was going to be.
- zik 9y ago
- shaki-dora 9y agoThis seems unnecessary hostile. It'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. Depending on how their CPU development pipeline works, it's quite likely that even the next generation will still be affected, giving everyone plenty of time later for such niceties. It's also slightly too harsh to call all of Intel's work "crap" when this bug has apparently existed for the better part of two decades without being noticed.
- pricetag 9y ago>unnecessarily hostile Not that I disagree with you, but are you familiar with Linus’ other uhhh...critiques? http://lkml.iu.edu/hypermail/linux/kernel/1510.3/02866.html http://lkml.iu.edu/hypermail/linux/kernel/1510.3/02866.html
- mcny 9y agoI agree with Linus though. Not that I've ever worked on a big project like the kernel but things like these will take a backburner. The kernel maintainers don't have a way to bring these things up in Intel's boardroom like Apple can and it is possible that Intel will never produce a proper fix.
- nkw 9y ago> had to be completed in a hurry "We reported this issue to Intel, AMD and ARM on 2017-06-01" https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html https://googleprojectzero.blogspot.com/2018/01/reading-privi...
- maxlybbert 9y agoI didn't take the comment as "all Intel CPUs are crap," but that (1) the fix is needed for crap CPUs and (2) the fix is turned on unconditionally on Intel CPUs, even future CPUs. That is, the code itself assumes that all CPUs that could be crap actually are crap. Torvalds wants a flag that could be set appropriately when Intel starts shipping CPUs that don't have this problem.
- 9y ago
- ysleepy 9y agoConsidering 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}.
- jhanschoo 9y agoCan I see an article/discussion about AMD being passive-agressive about it? I want my popcorn.
- mlosapio 9y agohttps://lkml.org/lkml/2017/12/27/2 https://lkml.org/lkml/2017/12/27/2
- none_to_remain 9y agoIt is dry - https://lkml.org/lkml/2017/12/27/2 https://lkml.org/lkml/2017/12/27/2
- cryptonector 9y agoHardly passive-aggressive. What would the alternative have been? Leave PTI on on AMD just out of sympathy for Intel?!
- eftychis 9y ago+1 :D
- yuhong 9y agoMy favorite is espfix. espfix64 is worse than espfix32 too. I have suggested limiting modify_ldt to root instead.
- revelation 9y agoLove it, an LFENCE on every indirect jump in core 32/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..
- bewaretheirs 9y agoIf I'm reading it correctly, the lfence is never reached for real (only speculatively..) code invoking the thunk pushes the target address on the stack, then branches to or calls the thunk. The first instruction of the thunk is a "call" to a nearby address, skipping over an infinite loop (2: lfence; jmp 2b) the lea n(%xsp),%xsp discards the return address pushed by "call", and the subsequent "ret" "returns" to the branch target rather than to label 2. perhaps the speculative execution engine doesn't take the stack pointer adjustment into account and so gets stuck in the lfence loop, only being snapped back to its senses when the lea completes..
- geofft 9y agoThis would be more convincing if the x86 CPU manufacturer he used to work for were still in business. 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 "competent" kernel developer would do, but since I don't run an equally successful, more secure kernel, it's just armchair quarterbacking.
- hossbeast 9y agoBut do you disagree with his points?
- geofft 9y agoYes, sort of - I don't think he has the evidence to claim that a competent CPU engineer would have done things in a certain way, because all the really theoretically good CPUs (and I count Transmeta among them!) seem to have not succeeded in the market nearly as well as the messy, awful ones, and a CPU that no longer exists doesn't actually count for anything. A competent CPU engineer is balancing lots of tradeoffs. It might be the case that he's right, but in the absence of evidence I weakly believe he's not, and I strongly believe that he's not in possession of strong enough evidence.
- foxylad 9y agoInteresting concept - we should discount all criticism except from equally or more successful companies than Intel? if geofft.karma >= foxylad.karma: print('No comment.') else: print('This was a really badly thought out comment.') So... No comment.
- userbinator 9y agoLooking at the patches Linus is commenting on: as an Asm programmer, this is absolutely horrible --- basically every indirect call (one instruction) turns into a seven-instruction sequence that will, due to preventing speculation, result in massive slowdowns: https://lkml.org/lkml/2018/1/3/770 https://lkml.org/lkml/2018/1/3/770 Unlike the KPTI patches, which only affect things on each system call, this happens on every indirect call and probably bloats the code considerably too. I can see why Linus is not happy. 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.
- revelation 9y agoI missed that, actually. But you are right, it's not just the crucial bits of inline assembly they are patching here, they expect your kernel to be built with their special version of GCC (yet unreleased) that mutilates every single freaking indirect jmp/call into what could cost more than a virtual function call.. We use a new compiler option -mindirect-branch=thunk-extern
- userbinator 9y agoI missed that it was indirect jumps too, which means switch statements also get affected. That's even worse.
- revelation 9y agoHere is an example with the very common programming patterns that result in indirect jumps/calls: https://godbolt.org/g/LPycpY https://godbolt.org/g/LPycpY Every single call rax and jump rax that you see on the right will be replaced with the following: push rax jmp .indirect_thunk And indirect_thunk does an lfence and a call to another function that gets rax from the stack and jumps there in a very roundabout way that interacts terribly with CPU prediction. I can see why they somehow didn't get around to benchmarking this yet, because they are not going to like the results. And it doesn't end with the kernel. Every JIT is going to need the treatment.
- godgod 9y agoLinus can be a real asshole
- mrmondo 9y agoWell said and I think Linus was especially well restrained or perhaps 'careful' with his wording here.
- alexeiz 9y agoLinus is getting old.
- jcranmer 9y agoThis is my understanding, please correct me if wrong: There's a basic class of bugs (let's call it Spectre-class) that'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. 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. Beyond these two bugs, there may exist other Spectre-class bugs specific to different architectures/vendors that are not yet thoroughly investigated. What did I get right and wrong?
- AlphaSite 9y agoAMD alleges that the fix for Spectrr can be ameliorated with minimal performance overhead.
- senatorobama 9y agoDoes this disable the branch predictor for all function calls?
- zorangus 9y agoLinus missed the bus. The Spectre attack doesn't require speculation across protection domains.