Slashdot Mirror
Despite 'Painful' Spectre Response, Linus Torvalds Says He Still Loves Speculative Execution (youtube.com)
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..."
"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.
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..."
"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.
Why not? The theory is great. The implementation sucked.
A guy in a suit that makes predictions?
RISC-V
J-Core
Open and auditable... closed implementations almost always lead to security problems.
According to http://secure64.com/not-vulnerable-intel-itanium-secure64-sourcet,
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.
Anons need not reply. Questions end with a question mark.
Despite 'Painful' Spectre Response, Linus Torvalds Says He Still Loves Speculative Execution
I love speculative execution too... in theory. Hypothetically. In truth, how I feel about it depends on certain considerations, to be determined.
Our reign has gone on long enough. Indeed. Summon the meteors.
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.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
OpenVMS for life in the security realm.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
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! :-)
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/
Of course news about a fake are Fake News.
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 confidential. Any leak from execution history is a possible side channel.
I recall reading in the early 1980s about the difference between concrete state and abstract state, around the time C++ started to take const seriously. A typical case study was a representation of a point on a plane, which automatically toggled between polar and Cartesian representation, depending on whichever proved most convenient for the last calculation. This makes the representation of the point inherently non-const, just for calculating on the point's value. But we justified this seeming const violation by distinguishing the abstract state (the location of the point) and the concrete state (the actual representation in memory at any given moment).
You rarely (or never) saw this kind of debate inside the functional languages, which practically by edict ban discussion of concrete state (repeat after me: in the view of the application programmer there is only the abstract state, in the view of the application programmer there is only the abstract state, ... but of course, any practical implementation was very tricksy under the hood with concrete optimization, which the application programmer was basically forbidden to understand, because interaction with the time domain is somebody else's hot, embarrassing mess.)
In the context of memory management, one can view the set of memory allocations as the abstract state, and the actual memory addresses backing those allocations as the concrete state. (This is why virtual machines are even possible.)
Distinctions between abstract and concrete state in silicon go at least as far back as the 80286.
x86 memory segmentation
The LOADALL Instruction by Robert Collins
Testing becomes horrific once a processor begins caching historical state. Intel was justifiably terrified of venturing into this strange, new territory.
Caching is inherently a form of prediction: a prediction that the last value used is worth hanging onto, in case it is soon used again. (Caching in most contexts is insanely productive, so empirically, this is an extremely good prediction.)
Processors could be designed to save any amount of their concrete process state (generally invisible, except as a side channel) at every context switch, and to then clear all branch predictors, all TLB entries, all cache lines (probably involves MESI broadcasts to other processors, also evicts cached page table translations, for when the TLB is too small).
What really makes speculative execution different is its invocation of Eternal Sunshine of the Spotless Mind and it's later miniaturization as the MIB neuralizer: leak concrete state into the process-visibl
Didn't the VMWare people see their hypervisor as the king of OS's--just a few years back?
https://www.youtube.com/c/BrendaEM
Be free to talk about any product, service in real time.
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.
Domestic spying is now "Benign Information Gathering"