Avoid speculative indirect calls in kernel
lkml.org
lkml.org
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.
We use a new compiler option -mindirect-branch=thunk-extern
Every single call rax and jump rax that you see on the right will be replaced with the following:
push rax
jmp .indirect_thunk
https://support.google.com/faqs/answer/7625886
http://webcache.googleusercontent.com/search?q=cache%3Ahttps...
(some websites with info on this are DoSd and down right now, including the Arm website and LLVM code review site so switched to a cache link)
Pretty painful for C++ but fixable with build changes. JVM users and other JIT-compiled languages will probably be fixable without any serious impact, as HotSpot and other advanced runtimes devirtualise calls (convert indirect to direct) as much as they can anyway, meaning most calls won't be indirect when finished and once the code has warmed up.
* https://reviews.llvm.org/D41723
Now, you can certainly argue that this particular tradeoff wasn't worth it, and in hindsight it's certainly a questionable one. However, do note that side channel attacks have been known for decades (since out-of-order CPUs became widespread in the 90s) and until this point have rarely presented a significant threat to most systems.
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?
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..
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.
Additionally: you might update infrequently when it comes to feature releases, but you'll definitely need security patches.
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..
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.
Differences in AMD architecture mean there is a near zero risk of exploitation of this variant. Vulnerability to Variant 2 has not been demonstrated on AMD processors to date.
Near-zero is not zero.
No, it's not the “technically correct way”. It's true that some style guides recommend something like this (but always, AFAIK, more limited); e.g., the New York Times style (and Chicago style) uses apostrophes for plurals of abbreviatiins formed with capital letters and periods, and plurals of single letters. [0] AP, on the other hand, only uses apostrophes for plurals of single letters, but not for abbreviations/initialisms/acronyms. Most British styles I've seen don't use apostrophes for plurals at all, IIRC.
[0] https://afterdeadline.blogs.nytimes.com/2010/04/13/faqs-on-s...
The general newspaper style is acronyms with periods use apostrophe to separate period from s. Therefore M.D.'s and Ph.D.'s are plural. Where period is not used in the acronym, the apostrophe is not used, so CPU not C.P.U., therefore it's CPUs. Anyway, it's just a convention, the key is consistency.
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.
Not that I disagree with you, but are you familiar with Linus’ other uhhh...critiques?
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.
"We reported this issue to Intel, AMD and ARM on 2017-06-01"
https://googleprojectzero.blogspot.com/2018/01/reading-privi...
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.
if geofft.karma >= foxylad.karma:
print('No comment.')
else:
print('This was a really badly thought out comment.')
First, I think that there's a distinction between constructive, humble criticism, of the form "Why can't the CPU be designed in such a way that ___", and statements like "Well, a competent CPU designer would have done ___". That distinction is not just politeness (although politeness is of intrinsic worth); that decision leads to better technical outcomes. There might be a good answer, like "It can't be designed like that because of the following constraints" or "We tried it and couldn't get it to work"; there might just be an answer like "That's totally the right thing to do and we just cut corners" or "We never thought of it but our competitor does that and it seems to work for them, yeah." Unlike arguments about how competent people actually are, these discussions contain actual technical content, and help different people understand each other's points of view (which is the whole point of having an online, public, decentralized development community, is it not?).
Second, yes, I think that we should discount, though not by much, criticism from people who say "I could totally do that in a better way" and have not actually tried to do that (or have tried and failed to launch a product). There's a lot of things about building complex systems (like modern CPUs) that aren't apparent on paper, and only become apparent once you try to reach some challenging level of scale or performance. This is not at all to say that there's no place for outside criticism; often outside criticism can offer fresh perspectives, or suggest a way to simplify the system and avoid the emergent problems of complexity. And often there are people who are genuinely qualified and really could build a better system, but happen to be working on something else. But it's still fundamentally outside criticism. The only people who can really say "Yes, you totally could have done this instead" are those who actually did.
Third, in this particular scenario, it happens to be the case that ex-Intel employees with insider knowledge have called out Intel for cutting corners (see the "Update" section of https://danluu.com/cpu-bugs/), which seems like a much more productive basis to have a technical conversation.
And if those stories are to be believed and if they're relevant to this problem, the problem is not the competence of engineers - the problem is the competence (or the confused incentives, really) of management who are not telling their engineers to invest time into doing things the engineers know perfectly well how to do, or are telling their engineers to invest time into building other features that make those things harder. (For instance, quite possibly some part of management got worried about benchmarks of syscall performance and told their engineers to prioritize that over making sure that there aren't side-channel leaks between rings.)
A rigorous argument for why foo can be done and doesn't kill your product would be fine too, but this email doesn't even attempt to do that. What can be asserted without proof can be dismissed without proof.
It was a clever microarchitecture; they just targeted the wrong consumer segment (breaking into x86 was nigh-impossible that late; chip internals on the other hand... =D)
Having said that, though, I think calling it "crap" is a bit much. But that's still a pretty mild/weak insult in Torvalds-speak.