Microsoft, Google: We've found a fourth data-leaking Meltdown-Spectre CPU hole

Re: Its quite depressing really

In this context encryption outside of the CPU doesn't really matter; the compromised processor is the thing that must touch decrypted data to, well, process it.

Re: Its quite depressing really

Half right, half wrong:

"They aren't copying each other, it's just that there's only so many ways to make something execute more instructions faster. And yes, speed is freaking important."

Right. Someone comes up with an idea that solves a perceived problem, and it gradually becomes standard practice, unless someone else comes up with a better solution. That's just the way a successful society makes progress.

"One of the important points of all of this is that too many applications don't encrypt sensitive data, even with minimal encryption."

Wrong. In general, things have to be in comprehensible form for processing. There are a few ways of doing certain limited operations on encrypted data, but this is orders of magnitude slower than operating on the unencrypted data. Better to just scrap speculative execution, as it is a much lower performance hit.

Re: Its *very* depressing really

"We have only (relatively) recently started accepting that malicious stuff will run on our computers (invited in by making the web able to run stuff locally)."

Are you serious? And, by the by, who is this "we"?

Long before the era of ubiquitous web access, it was quite popular for someone to send someone else this week's weekly spreadseet (or whatever) and it has a macro in it that does the equivalent of "format c:" I'm thinking that goes back to the 1990s, when MS and IT departments had discovered email but the unprotected web hadn't become ubiquitous.

And because the underlying commodity software people and commodity sysadmin people typically had no systematic concept of protecting their important resources (files and filesystems, for example) against inappropriate access (stuff visible that shouldn't be, stuff writable that shouldn't be), such matters being beneath outdated relics of a forgotten era where security and access controls *had* to be considered as part of a bigger picture, the rest of us end up two decades later with an industry literally subject to Meltdown.

Maybe the IT crowd should switch it off and switch it on again and see if it works better afterwards. It seems to be the industry standard approach.

Re: Its quite depressing really

A better word might be that we have to be paranoid.

We used to look at things from above. Privilege etc. Now we need to become paranoid and see what ways people can get to us from all sorts of obscure angles.

Re: Its quite depressing really

"the fastest chip possible and not have to think about the security of it."

That's probably a reasonable starting point for designing a system to run the DOS version of Crysis - no need to consider data security or data integrity, no need for access controls like real computers used to have, just make that frame rate the fastest you can.

For anything more realistic, there may be other fundamental considerations, along the lines of "should this instruction in this process with these access rights be permitted this kind of access to this kind of object".

I'm struggling with some of the published descriptions of "rolling back" the consequences of mispredicted speculative execution.

As far as I understood it, one of the fundamentals of getting speculative execution to work right in the real world (it's not easy, but it's not impossible either given sufficiently clear thinking) is that the results cannot become visible 'elsewhere' (e.g. to other applications), directly or indirectly, until the speculation up to that point is fully confirmed as correct. Hence multiple 'shadow' register sets and reservation stations and other such well documented and (I thought) well understood stuff.

Shadow register sets provide multiple virtual (god i hate that word) copies of the real internal processor registers for speculative instructions to play with. Once it's determined which instruction stream gets to execute to completion, all the now-irrelevant copies aren't "rolled back", they're marked as outdated, and only the successful values are allowed to be used for further work. In any case, any speculative values *must not* be used for anything that will become visible in the outside world, e.g. a speculative load from real cache - such an operation cannot be "thrown away", and in the right circumstances potentially becomes a route for data leakage.

Part of this is about processor architecture, part of it is about OS security. All of it requires clear thinking, not just a focus on 'how do we make this code sequence run faster' while forgetting the bigger picture - e.g. should this code sequence be permitted to execute at all.

There used to be people who understood these things.

Re: Its quite depressing really

"Maybe I don't see these things as I'm not criminally minded".

THIS. This is the mentality that made my time in microprocessor validation so...fruitful. This is the same mentality I tried to beat out of my calculus students. It's not lack of criminality, it's lack of rigor.

I don't know how engineers are trained, but the important part of a mathematician's training is to find the edge cases that you missed the first time around. And the second.

Re: Its quite depressing really

"Maybe the engineers that design the CPUs think the same. They just want to design the fastest chip possible and not have to think about the security of it."

In part, it's a matter of metrics. Engineers are not particularly rewarded for producing theoretically secure chips, they are rewarded for producing faster chips on time for the sales types to hype them as faster than the competition.

In part, it's because a few engineers have months or years to design incredibly complicated chips, many many attackers, some lavishly supported by nation states, some by criminal organizations, some in a quiet basement somewhere have decades to find the small flaws that can be exploited.

Re: Its quite depressing really

"Federico Faggin designed the Z80 in 1974. It was, I'd bet, the last non-risc CPU that one person could get their head round. Since then people have designed bits of CPUs but how the hole thing works, along with the non too simple problem of the operating system running on it, is beyond one persons ability to fully understand."

Off hand I don't know the exact date or chip generation, but it's been decades since CPUs were designed directly by humans, rather than by human guided design tools. That has to translate to a lessened understanding of what is going on 'under the hood' in detail... not that humans could do all the circuit analysis the tools do, even in a lifetime, for a chip with tens or hundreds of billions of transistors, data paths, etc.