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.

Comments

Of course he does

[Snotnose]

Why not? The theory is great. The implementation sucked.

Re:Of course he does

[WorBlux]

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:Of course he does

[ebyrob]

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 I have to let users see some dancing bunnies sometimes, but do the bunnies have to dance fast? Especially so fast they can't pause for some basic software bounds-checking.

Re:Of course he does

[Anonymous Coward]

You do realize your first part of your first line just spelled out most of where the implementation sucks, right? Side effects were a known side channel, but the feeling was the risk was low because attacks would be difficult. While certain side effects are nearly unavoidable with speculative execution--the speculative execution happening or not is itself possibly time-able even with cache attacks--the actual known risks of cache attacks was blatantly obvious precisely because cache hits/misses are very noticeable. It should have always been a requirement for caches to be restored because they're a type of memory too.

Re:Of course he does

[Anonymous Coward]

You do realize your first part of your first line just spelled out most of where the implementation sucks, right?

Let me FTFY and you'll be able to figure out what he was saying:

You do realize your first part of your first line just spelled out most of where the concept is completely flawed, right?

It's not the implementation that's the problem. EVERY IMPLEMENTATION OF SPECULATIVE EXECUTION WILL HAVE THOSE FLAWS.

If you don't believe me, think about it for two seconds: if it doesn't have the side effect of reducing the time taken to run code under certain circumstances, then what is the point of having it in the first place?

Believing this to be an implementation issue is evidence you don't understand what speculative execution is.

Re:Of course he does

[Anonymous Coward]

This is effectively like caching, only with instructions. It's an excellent idea given the transistor count available - the implementation just put speed before security, which is typical management bullshit.

Re:Of course he does

[citizenr]

>The implementation didn't suck

Dude, intel implementation IGNORED privilege boundaries.

Re: Of course he does

[Anonymous Coward]

It is All pointless as long as they deliberately put backdoors in a All CPUs either by choice or because they are forced

We desperatly need a non US CPU Maker that might be more able to resist the pressure from 3 letter agencies and resist the lure for a Quick buck by adding backdoors etc

Re: Of course he does

[Anonymous Coward]

Exactly.. Assuming Intel fpgas are free of
backdoors and thats a big assumption then vampire systems might be the Best bet

Re:Of course he does

[Z00L00K]

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 again.

Re:Of course he does

[fahrbot-bot]

The theory is great. The implementation sucked.

Humanity seems to be like that too ...

Re:Of course he does

[Anonymous Coward]

Mod up. However asking the hypervisor to do some scrubbing before switching, and setting interrupts before and after in software is NOT a bug but unnecessary enhancement when Intel DO fix ALL the problems, or the deliberate compromise they chose to make secretly. Now there will be interrupt gaming. Now if a rocket or guidance system still uses intel after this, lookout. Context switching is going to be a dog now, and the scheduler will not be pretty if we add a global security setting for particular tasks, including the master security task.

Re:Of course he does

[Wrath0fb0b]

Dude, intel implementation IGNORED privilege boundaries.

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:Of course he does

[Anonymous Coward]

They ignored the privilege check when accessing the cache (MELTDOWN)!

Re:Of course he does

[Anonymous Coward]

If you don't believe me, think about it for two seconds: if it doesn't have the side effect of reducing the time taken to run code under certain circumstances, then what is the point of having it in the first place?

The point is that the side effect has to be detectable in some fashion to be a threat. More specifically, in real world applications specific speculative executions have to detectable and not merely the aggregate some percentage of speculative execution occurring*. It's why cache hits/misses (along with other translation buffers) in execution are such an attack vector. It's why I'd say that as much as the theory is probably unobtainable (because you might be able to tease some information out of the aggregate and/or very small timing differences may be magnify-able), the actual implementation was simply horrible because cache is an unprivileged attach vector which was well understood.

Believing this to be an implementation issue is evidence you don't understand what speculative execution is.

To draw an analogy, I know it's impossible for someone to smuggle a bomb on a plane, but it'd be a bad implementation if the gift shop in the airport sold bombs beyond any security checkpoint. Just because the goal is impossible doesn't mean implementations can't be bad.

Re:Of course he does

[Anonymous Coward]

I think it somewhat depends on context. Speculation is valuable but needs to be controlled.

Speculative execution needs to reduce the time taken to run the code by correctly predicting which parts of the code will execute.

If those predictions are made using values that should not be observable, you've got an information leak.
If those predictions are made only using observable values, then you do not.

But of course the question is: what should be observable?
- If your code accepts user data, processes it, and reports it back to the same user, then predictions based on non-speculative execution violates no security boundaries.
- If your code accepts data from different users and processes it, then the same prediction model may violate security boundaries.

This could be an opportunity for improved speculation. Suppose you're writing a virtual machine that runs sandboxed code. A mechanism that allows us to limit speculation from crossing across sandbox boundaries could also improve speculation within a sandbox by limiting pollution from other tasks.

Re:Of course he does

[citizenr]

it speculatively executed _unprivileged code_ past them

thats called "ignored"

Re:Of course he does

[Anonymous Coward]

it speculatively executed _unprivileged code_ past them

thats called "ignored"

It being the processor itself, not your process.

Not much different than you asking to read a file, the kernel simultaneously issuing IO to read both data and metadata, then not giving your process the data because of permissions. The kernel would be free to do that, because it is not unprivileged, you are.

I wish people would stop burying their heads in the sand in regards to the cache timing attacks, it’s as important as coaxing the cache to be filled with something you can’t read. It’s not like the processor is just handing data over.

Re:Of course he does

[Anonymous Coward]

They ignored the privilege check when accessing the cache (MELTDOWN)!

That’s not what happens at all, because data is only inferred from the cache, slowly, through a type of timing attack.

Re:Of course he does

[Anonymous Coward]

Why not? The theory is great. The implementation sucked.

So he is not speculative at all? Now I am confused!

Re: Of course he does

[tkotz]

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:Of course he does

[Agripa]

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:Of course he does

[WorBlux]

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 pipeline.Speculation can be done without these flaws, it just gets less cost effective to do so. I do hope the mill architecture makes an appearance soon, as high-performance and low-power for general purpose code without speculation would be nice.

Re:Of course he does

[WorBlux]

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.

Speculative Executive?

[Anonymous Coward]

A guy in a suit that makes predictions?

Re:Speculative Executive?

[Anonymous Coward]

Painful speculum response by spectre-loving Torvalds?

Re:Speculative Executive?

[K. S. Kyosuke]

He meant an OS kernel, obviously. Otherwise also known as monitor, supervisor, core, nucleus...

Re: Speculative Executive?

[Anonymous Coward]

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"

Re: Speculative Executive?

[Anonymous Coward]

I think the original headline shows the editors have no more than recruiter-level knowledge of technology. Which is to say they only can recognize tech keywords and use them in a sentence without knowing anything about their meaning

Open architectures

[Anonymous Coward]

RISC-V
J-Core

Open and auditable... closed implementations almost always lead to security problems.

Re:Open architectures

[Anonymous Coward]

Security problems in the name of "security". (Cue flags waving, trumpets...)

Re:Open architectures

[Anonymous Coward]

Intel hides itself in the obscurity.

"Speculative Execution" is as to kill first and later to unkill the satisfied ones (as zombies).

Three main problems of the "Speculative Execution" are:
1. Hardware's complexity too excessive and could commit bugs in hardware.
2. Security: many flaws everywhere due to the hardware complexity.
3. Energy requirement: it rises the TDP and the CPU temperatures due to many discarded computations (calculated and invalidated is as discarded the energy of their works ).

Itanium beats x86

[Anonymous Coward]

According to http://secure64.com/not-vulnerable-intel-itanium-secure64-sourcet,

The Itanium platform is naturally immune to both Spectre and Meltdown precisely because the complex, expensive methods used to speed up a 44-year old architecture are completely absent in Itanium.

Itanium execution is explicitly parallel. It is the job of the compiler or coder to lay out the instructions and tell the hardware what can be done in parallel. Linus once quipped that he’d like to see an out-of-order Itanium (probably something he regrets saying, now), showing himself clueless about what EPIC and Itanium were about.

Without out-of-order execution, there is no way for the Meltdown attack to work.

Likewise, there is no speculative execution in Itanium. Instead, the architecture provides powerful branch prediction and predication, a concept generalized from ARM (sadly, abandoned in AArch64) to avoid branching altogether.

Re:Itanium beats x86

[Waffle Iron]

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:Itanium beats x86

[ArchieBunker]

You'd think Itanium hardware would be near worthless on eBay but it's not. How else can you run OpenVMS these days?

Re:Itanium beats x86

[Anonymous Coward]

How else can you run OpenVMS these days?

Runs just fine on a VAX or Alpha emulator like SimH or FreeAXP. Hell, you've been able to run VMS on a Raspberry Pi for years in this manner.

Re:Itanium beats x86

[Sique]

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?

Re: Itanium beats x86

[Anonymous Coward]

Is he not talking about a regular VM? You can run a vm on a ti86 if im not mistaken

Re: Itanium beats x86

[Anonymous Coward]

I wonder what might happen if you designed a branch predictor with extremely long branches and pipeline depth then just let nature take its course with modern system resources. Seems a lot like Conway's game of life and neural networks used for machine learning but with multidimensional cellular automata exploring raw data input combinations until a condition is met or the number of compute clock cycles or iterations without a resolution is unacceptable due to lack of available resources or time.

Re:Itanium beats x86

[Anonymous Coward]

Itanium is a VLIW (Very Long Instruction Word) processor, which means that speculation is controlled at compile-time, not at run-time. One of the early papers on the subject described it in the following way (note the passage that I have emphasized):

... run-time speculation is expensive in the hardware needed to support it. The alternative is to perform speculative code motion at compile-time. The compiler for a VLIW machine specifies that an operation be executed speculatively by performing speculative code motion, that is, scheduling an operation before the branch that determines that it should, in fact, be executed. At run-time, the VLIW processor executes these speculative operations in the exact order specified by the program just as it does for non-speculative operations. These operations will end up being executed before the branches that they originally were supposed to follow; hence, they are executed speculatively in relation to the original sequential code that the scheduler received....

When the compiler decides to schedule operations for speculative execution, it ensures that they do not overwrite any of the state of the computation that is needed to assure correct results if it turns out that that operation ought not to have been executed. This is achieved by writing the results of the speculative operations into different destination registers, i.e., performing register renaming at compile-time.

Re:Itanium beats x86

[ArchieBunker]

Real hardware is always more fun. I've had VAXstations in the past but sold them, sadly.

Re:Itanium beats x86

[Agripa]

And Itanium also provided less performance because the magic compilers it relied on never achieved the predicted level of performance.

Re:Itanium beats x86

[Agripa]

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 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:Itanium beats x86

[lsatenstein]

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?

Suggestion:

[Gravis Zero]

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:

[MAXOMENOS]

Intel is a Platinum Member of the Linux Foundation - which, btw, doesn't just sponsor the Linux kernel, but a bunch of projects, similarly to the Apache Foundation. Does this satisfy?

Re:Suggestion:

[Waffle Iron]

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:

[ebyrob]

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:Suggestion:

[Anonymous Coward]

I'd love to get an insult like that.

Re:Suggestion:

[Andtalath]

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:Suggestion:

[Anonymous Coward]

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:

[thegarbz]

That's the entrance fee. They also actively contribute time and effort to contribute.

Re: Suggestion:

[Anonymous Coward]

Think about it in terms of percentages rather than raw numbers. Spending the bare minimum to have the most control or influence seems a lot like how some huge companies avoid tax using loopholes too. There should be legislation to set a minimum percentage contribution for core systems security and safety, just like the governments spend on their cyber defence budgets.

Re:Suggestion:

[drinkypoo]

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:Suggestion:

[Anonymous Coward]

So how much is written by the NSA? Of course I'm talking about SELinux, nothing else. Wink, wink.

Re:Suggestion:

[Anonymous Coward]

I wonder how much of that time is dedicated to sabotage their competitors.

That's exactly what I thought when I saw they contribute heavily to the Linux kernel.

Re: Suggestion:

[Anonymous Coward]

Are you mentally ill?

Huh?

[Anonymous Coward]

Huh?

Maybe.

[Hallux-F-Sinister]

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.

Re: Maybe.

[Anonymous Coward]

I see what you did there. What a throwaway comment!

Re:Maybe.

[GuB-42]

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:Maybe.

[Hallux-F-Sinister]

You should take decisions assuming speculative execution is good. If you are wrong, you can always undo what you've done and start again.

But what if someone reads my mind to learn what I would have done had things turned out a particular way with speculative execution, because my brain is not designed to dispose properly and securely, of any possible results of considerations of what I might do if things turn out differently? Then what?

Just... asking for a friend.

Caring more about software and key hardware

[SuperKendall]

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.

Re:Caring more about software and key hardware

[Anonymous Coward]

I think Linus is right about software too, limited speculative execution is great, but I wish the huge effort spent building bigger and more complex out of order processors had been spent on fundamental research into better logic families / memory / IO. Be it graphene, Mott effect devices, GAN, GaAs. Philosophically I'm in the Cray camp, address the fundamental physics and limits head-on.

History Lesson

[Anonymous Coward]

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.

If history has taught us anything, it's that the next major revision already contains a new set of security bugs. We also know from history that it'll take security researchers decades to find the new vulnerabilities. Once they find the new bugs them we'll all say "yeah, we already knew that was theoretically possible even before the hardware was released, but we didn't think anyone could exploit it."

Next, everyone will freak out for a few months about "OMG you have to patch this immediately or you'll be owned" -- except everyone is already owned, and there's nothing a patch can do to help if you're already rooted. The only way to be sure is to give the hardware a nice bath in Aqua Regia to remove the precious metals before pulverizing the remainder into dust and then setting it on fire. Oh, yeah, and destroy your backups too, because they're also compromised.

Re: History Lesson

[Anonymous Coward]

We're already compromised at birth. Paranoia doesn't help security. In real life you address targets of value to protect vs costs of protecting such values.

Re: History Lesson

[Anonymous Coward]

Paranoia is the best thing ever for security because it takes into consideration both that which is true but is not thought to be true, and that which is thought to be true but is not. Your assumptions about the simplicity danger are dangerous.

Re:Torvalds is a moron

[Z00L00K]

OpenVMS for life in the security realm.

chief open software

[Anonymous Coward]

Engineer who is a wall street crooks bitch...

Is Linus a cat ?

[Alain Williams]

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:Is Linus a cat ?

[Hallux-F-Sinister]

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! :-)

Inasmuch as he's currently alive, the only way to ensure he never dies is to watch Linus Torvalds 24 hours a day, 7 days a week... actually, there's probably not just a few organizations already doing that, so... I expect he'll live forever.

On an almost completely unrelated note... OH MY GOD If I had a tomcat, I would totally name him Linus.

Then I'd get a little mouse, you know, one of the ones they raise to give to snakes? The mouse I would name Nvidia.

Hehehe... :) That'd be fun.

It's somewhat sad that then people didn't ...

[Plumpaquatsch]

Wow, careful there Linus. Forgot all about the Copy On Write bug that you fixed in the Linux kernel in 2005, but which you then unfixed, declared "theoretical" and which was then ignored for over a decade until it hit the fan in 2016?

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/

abstract state / concrete state prehistory

[epine]

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 privilege check is done only when the segment register is loaded, because segment descriptors are cached in hidden parts of the segment registers.

The LOADALL Instruction by Robert Collins

The 286 LOADALL is widely known because a 15-page lntel confidential document describing its use was given to many developers.

Intel originally included LOADALL in the CPU mask for testing purposes and In Circuit Emulator (ICE) support. ... LOADALL loads all of the software-visible registers such as AX, and all of the software-invisible registers such as the segment descriptor caches.

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

What does a VMWare Have to Do With Open Source?

[BrendaEM]

Didn't the VMWare people see their hypervisor as the king of OS's--just a few years back?

Let capitalism work

[AHuxley]

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.

Transmeta

[Anonymous Coward]

What ever happened to them? I know their processors sucked, but did the technology live on?

Re:Speculative Execution?

[Anonymous Coward]

A guy in a suit that makes predictions?

A spectre of a former executioner that makes predictions using a medium?