Despite 'Painful' Spectre Response, Linus Torvalds Says He Still Loves Speculative Execution (youtube.com) 82
At this year's Open Source Summit, Linus Torvalds sat for a wide-ranging "keynote" interview with Dirk Hohndel, chief open source officer at VMWare, which has been partially transcribed below. And Linus explained, among other things, why the last merge window was harder than others:
One of the issues we have is when we've had these hardware security issues, and they've kept happening now, the last year -- they're kept under wraps. So we knew about the issue for the last several months, but because it was secret and we weren't allowed to talk about it, we couldn't do our usual open development model. We do the best we can, and people really care deeply about getting a good product out, but when you have to do things in secret, and when you can't use all the nice infrastructure for development and for testing that we have for all the usual code, it just is way more painful than it should be. And then that just means that, especially when the information becomes public during what is otherwise a busy period anyway, it's just annoying...
I still love speculative execution. Don't get me wrong. I used to work for a CPU company. We did it in software, back when I worked there. I think a CPU has to do speculative execution. It's somewhat sad that then people didn't always think about or didn't always heed the warnings about what can go wrong when you take a few shortcuts in the name of making it slightly simpler for everybody, because you're going to throw away all that work anyway, so why bother to do it right. And that's when the security -- every single security problem we've had has been basically of that kind, where people knew that "Hey, this is speculative work. If something goes wrong we'll throw all the data away, so we don't need to be as careful as we would otherwise." I think it was a good lesson for the industry, but it was certainly not a fun lesson for us on the OS side, where we had to do a lot of extra work for problems that weren't our problems.
It feels somehow unfair. I mean, when we have a security bug that was our own fault, it's like, "Okay, it was us screwing up. It's fair that we have to do all the work to then fix our own bugs." But it feels slightly less fair when you have to fix somebody else's...
"The good news -- I mean the really good news, and I'm serious about this -- is that the bugs have become clearly more and more esoteric," Linus adds. "So it impacts fewer and fewer cases, and clearly hardware people at Intel and other places are now so aware of it that I'm hoping we're really getting to the dregs of the hardware security bugs, and going forward we'll have much fewer of them. I think we're going to the better days, when A.) we got the bugs fixed, and B.) people were thinking about them beforehand."
There's a lot more, so read on for more excerpts...
When it comes to quantum computing, Linus says he's "a huge unbeliever in that whole thing. I don't think it will ever happen. And if I'm wrong, I'm pretty sure that I'll be long dead by the time people can prove me wrong..."I still love speculative execution. Don't get me wrong. I used to work for a CPU company. We did it in software, back when I worked there. I think a CPU has to do speculative execution. It's somewhat sad that then people didn't always think about or didn't always heed the warnings about what can go wrong when you take a few shortcuts in the name of making it slightly simpler for everybody, because you're going to throw away all that work anyway, so why bother to do it right. And that's when the security -- every single security problem we've had has been basically of that kind, where people knew that "Hey, this is speculative work. If something goes wrong we'll throw all the data away, so we don't need to be as careful as we would otherwise." I think it was a good lesson for the industry, but it was certainly not a fun lesson for us on the OS side, where we had to do a lot of extra work for problems that weren't our problems.
It feels somehow unfair. I mean, when we have a security bug that was our own fault, it's like, "Okay, it was us screwing up. It's fair that we have to do all the work to then fix our own bugs." But it feels slightly less fair when you have to fix somebody else's...
"The good news -- I mean the really good news, and I'm serious about this -- is that the bugs have become clearly more and more esoteric," Linus adds. "So it impacts fewer and fewer cases, and clearly hardware people at Intel and other places are now so aware of it that I'm hoping we're really getting to the dregs of the hardware security bugs, and going forward we'll have much fewer of them. I think we're going to the better days, when A.) we got the bugs fixed, and B.) people were thinking about them beforehand."
There's a lot more, so read on for more excerpts...
"Hey, it has been known to happen that I've been wrong before, so maybe the whole quantum thing is going to be a thing. But I think if you actually look at where hardware is going today, the much more relevant part is that traditional computers are not scaling, and people really don't see a lot of realistic paths forward to go on the hardware side. And I actually think that's probably healthy for the industry, eventually, and especially for us software people who have gotten kind of complacent...
"The saying used to be that every two years performance doubles, and that has clearly not been very true lately, and it's not going to be true going forward. And I think that's good. Maybe not fun, but it means that we'll maybe go back partly to the time where you cared more about performance on the software side, and you had to be more careful, and you can't just rely on hardware getting better all the time... I do think it's pretty clear that the whole Moore's Law thing is definitely not something you should take for granted. This very much impacts the hardware people, but I'm saying it also impacts, I think, us software people and especially us system people, where it means that software itself has to take that into account...
"I'm a software person, so asking me about hardware is kind of questionable to begin with. I'm actually a huge believer in neural networks. Back way in the days when I was at University, I was studying artificial intelligence -- the traditional kind of artificial intelligence -- and always felt that that was snake oil, and that the real model of AI is to actually look at what we know works, right? And I'm really happy to see that this is clearly the direction that the industry has been going lately."
Watch a 40-minute video of Linus's remarks on the Linux Foundation's page on YouTube.
Of course he does (Score:3)
Re:Of course he does (Score:4, Informative)
The theory requires you to eliminate side effects to be secure, but to speculate to any depth of calculaton you need access to intermediary results (e.i side effects). The implementation didn't suck, it was a very good implementation, but speculation at its core has a strong rellelence to security. To actually do it securely you need a lot of setup, adding costs to context switches, or you need to to design the pipeline to guarantee an undo on failed speculation including undoing the side effects such as cache loads and evictions.
Re: (Score:3)
So the VM envelope is broken and has vulnerabilities. That's a big deal and it's great it can be fixed. That makes sense. But how did it ever become a good idea to Just In Time compile javascript in the browser environment and rely on the hardware instruction set to keep us safe? That really seems like the major problem here. I don't see how anyone could ever expect to run potentially hostile web scripts at full native speed. Nor why they would want to if they bother to stop and think about it.
I know
Re: (Score:1)
I know Chinese, Russian and Indian companies all make CPUs if you trust those government's intelligence services more. And lots of FABs make licensed ARM chips.
I assume you are running all OSS as any US made closed source software would probably be a bigger potential leak than the CPU.
The question is: Who do you trust and what does the lack of trust cost ?
Re: (Score:2)
Speculation doesn't reduce the amount of time needed to run code, it reduces the amount of time the processor is idle by letting you run out-of-order across branch instructions. The problem isn't in running out of order, it's running instructions before permissions are checked and not unwinding every side effect. Intel didn't do it because direct access to those effects still isn't allowed, and doing a proper unwind would increase the branch misdirect penalty, or significantly complicate the instruction p
Re: (Score:2)
AMD avoided some of it by forcing separate page tables to be used for different permission rings, user code being speculated couldn't access kernel memory, because it had no clue what the physical address actually was.
Re:Of course he does (Score:4, Informative)
>The implementation didn't suck
Dude, intel implementation IGNORED privilege boundaries.
Re: (Score:3)
It didn't IGNORE them, it speculatively executed past them and then ROLLED BACK all visible result.
The bug was not in executing over the boundary at all, it was that the roll-back did not also reverse the side effects to the cache.
Re: (Score:2)
They ignored the privilege check when accessing the cache (MELTDOWN)!
The privilege check was ignored (not done) at the load but was caught at instruction retirement like other faults. This had the disastrous side effect of allowing the processor to execute speculative instructions on privileged data while not causing a fault because the speculated instructions were never committed.
To me the odd thing was that AMD did not suffer from the same problem. What made them decide to check privilege levels at the load instruction instead of at instruction retirement?
Re: (Score:2)
it speculatively executed _unprivileged code_ past them
thats called "ignored"
Re: (Score:2)
I can fully understand speculative execution with the processors of today when you can do a lot of parallel complex work and then throw away the results you don't need at the moment. This can lead to a vulnerability similar to the Enigma machine. Not exactly like it, but a remote similarity.
One of the vulnerabilities with the Enigma was that the output character could never be the same as the input character. So if that occurred then you as a code breaker could scrap that message decoding attempt and try ag
Re: (Score:2)
The theory is great. The implementation sucked.
Humanity seems to be like that too ...
Speculative Executive? (Score:3, Funny)
A guy in a suit that makes predictions?
Re: (Score:2)
Re: Speculative Executive? (Score:5, Informative)
Damn, they fixed the headline. Just so they can't hide it, the original headline was "Despite 'Painful' Spectre Response, Linus Torvalds Says He Still Loves Speculative Executive"
Open architectures (Score:1)
RISC-V
J-Core
Open and auditable... closed implementations almost always lead to security problems.
Itanium beats x86 (Score:5, Interesting)
According to http://secure64.com/not-vulnerable-intel-itanium-secure64-sourcet [secure64.com],
Re: (Score:3)
It would probably be easy to make an X86 just as safe and just as slow as the Itanium by simply disabling X86 speculative features altogether.
Re: (Score:2)
You'd think Itanium hardware would be near worthless on eBay but it's not. How else can you run OpenVMS these days?
Re: (Score:2)
Real hardware is always more fun. I've had VAXstations in the past but sold them, sadly.
Re:Itanium beats x86 (Score:4, Informative)
Branch prediction was introduced to keep the pipelines of the processor as much filled as possible. Branch prediction without speculative execution does not make any sense. Why would I try to estimate beforehand what branch the process is taking when I don't use that estimate for anything?
abstract state / concrete state prehistory (Score:2)
Deterministic prediction is not a problem. Simple case: predict short, relative, backward conditional jump 100% taken.
But do speculate on this guess carefully: never allow a data-derived address (non-deterministic) to modify any internal processor state until the access checks are complete (not even page tables or TLB entries, much less cache lines or MESI bits).
Prediction which tracks execution history (branch prediction tables) is far more troublesome. Execution history must be regarded as process confide
Re: (Score:2)
Branch prediction without speculative execution does not make any sense.
Speculative execution without branch prediction also does not make sense except in very special applications. It exists as eager execution [wikipedia.org] but costs so much more power than branch prediction that it is not worth it except in applications where performance at any cost is needed.
Re: (Score:2)
Branch prediction is speculative execution. If I have a pipelined processor, and the process execution arrives at a branch statement, I can either hold execution until the condition for the branch statement is calculated. Then the pipelines of my processor run empty until the calculation of the condition has finished. Or I predict the branch the execution is going to and start to fill up the execution pipeline with the commands of the branch I predicted and start decoding and executing them. But that is speculative, as the exact value of my condition is not known yet.
Branch prediction was introduced to keep the pipelines of the processor as much filled as possible. Branch prediction without speculative execution does not make any sense. Why would I try to estimate beforehand what branch the process is taking when I don't use that estimate for anything?
I'm an old codger, but I remember IBM system engineers telling me that their 3090 or more recent systems had 21 instruction look ahead. They actually decoded both sides of the compare statement, so that there was minimal lost time at the branch.
A few lookahead instructions to discover a comparison and the few instructions setup for either side of the branch.
The question to answer is "what do you do with the microcode data setup for the branch not taken?
Re: (Score:2)
And Itanium also provided less performance because the magic compilers it relied on never achieved the predicted level of performance.
Suggestion: (Score:4, Insightful)
Intel should show a bit of appreciation and donate like... ten million to a large pool of unfunded/underfunded open source software projects (especially projects with kernels that had to make fixes). Frankly, it would be a good PR move in the wake of their eternally shitty chips and make less people hate them.
As for me, I still know they are anti-competitive rat bastards and will keep buying AMD.
Re:Suggestion: (Score:5, Informative)
Re: (Score:3)
There are lots of members of the Linux Foundation, but most of them don't repeatedly inflict thousands of man-hours of emergency bug fix work on the core developers.
Re:Suggestion: (Score:5, Informative)
Intel is by far the single company writing most of the linux kernel.
Nr 1: Intel 12.9%
Nr 2: Red Hat 8.0%
The rest are 4% or under, while about 15% can not be attributed to companies.
Meaning, a lot of those man-hours ARE intel man-hours, especially since they primarily focus on making their own hardware work well in linux...
Re: (Score:2, Interesting)
I wonder how much of that time is dedicated to sabotage their competitors.
Like the first Intel-sourced Meltdown-patches explicitly hamstrung all x86 cpus in the name of "security", and the AMD people had quite a fight to stop it from being in inflicted on them, remember?
I wonder how much of that is going on that we never hear of.
Re:Suggestion: (Score:5, Interesting)
And yet the only thing that works better with intel than AMD under Linux is power management. Why does it take so much more code for intel hardware to work correctly than AMD? Errata?
Re: (Score:2)
Platinum membership is a paltry $500k. Enough to keep the lights on in a couple server rooms, but not nearly $10 million. On revenues of $65 billion, it's actually kind of insulting.
Re: (Score:2)
That's the entrance fee. They also actively contribute time and effort to contribute.
Re: (Score:3)
OpenVMS for life in the security realm.
Comment removed (Score:5, Insightful)
Re: Maybe. (Score:1)
I see what you did there. What a throwaway comment!
Re: (Score:2)
You should take decisions assuming speculative execution is good. If you are wrong, you can always undo what you've done and start again.
Re: (Score:2)
Caring more about software and key hardware (Score:1)
I think Linus is right, we are reaching a time where software efficiency will start mattering more.
But along with that means that it will also be key to understand what the capabilities are of possible hardware you may have at hand. From use of the GPU for specialized processing, to a better understanding of really low level things like registers in relation to the code your compiler is generating... all of that could be brought into greater consideration going forward.
Is Linus a cat ? (Score:2)
It seems that we don't know if he will be dead or alive when we learn if quantum computing will or will not work! :-)
Re: (Score:2)
It's somewhat sad that then people didn't ... (Score:3)
This is an ancient bug that was actually attempted to be fixed once (badly) by me eleven years ago [] but that was then undone due to problems on s390 [W]hat used a purely theoretical race back then has become easier to trigger.
https://nakedsecurity.sophos.com/2016/10/21/linux-kernel-bug-dirtycow-easyroot-hole-and-what-you-need-to-know/ [sophos.com]
What does a VMWare Have to Do With Open Source? (Score:2)
Let capitalism work (Score:2)
Talk to a community and suggest moving to better hardware in real time.
Users can then make a real time selection of better products that are secure.
Find better brands.