Another Intel Chip Flaw

Remember the Spectre and Meltdown attacks from last year? They were a new class of attacks against complex CPUs, finding subliminal channels in optimization techniques that allow hackers to steal information. Since their discovery, researchers have found additional similar vulnerabilities.

A whole bunch more have just been discovered.

I don't think we're finished yet. A year and a half ago I wrote: "But more are coming, and they'll be worse. 2018 will be the year of microprocessor vulnerabilities, and it's going to be a wild ride." I think more are still coming.

EDITED TO ADD (6/13): A mathematical analysis of the problem that claims we'll never completely fix this class of problems.

Posted on May 16, 2019 at 9:28 AM • 14 Comments

Comments

Clive RobinsonMay 16, 2019 12:57 PM

Ahh, that Xmas gift that just keeps giving and giving...

I'm guessing atleast another three years or so to go on the giving...

Clive RobinsonMay 16, 2019 1:09 PM

There is another issue with this speculative execution, it' very very expensive for what can be delivered in other ways.

In essence the hardware involved is both large and power hungry and consumes a significant number of resources. Becaus it runs at "full tilt" it runs hot very hot and thus takes up more real estate than it might otherwise do (look up heat death against die size).

Arguably software tools such as compilers if they know the architecture can reduce the %gain from speculation in a number of ways.

Thus getting rid of it on multiple cores would enable other similarly reduced cores for the same real estate, which whilst reducing each cores through put marginaly could on aggrigate over all the cores increase performance for certain types of programs.

The problem is getting enough data to quantify the pros and cons.

NickMay 16, 2019 1:16 PM

Do you think these attacks will be limited to CISC or will people start finding the same things in RISC chips?

Clive RobinsonMay 16, 2019 3:15 PM

Further to my above,

I should make it clear that I'm only talking about removing some of the speculation not all of it.

Speculation is if you like multi-layered in it's development. That is there are simple types of speculation that give quite an advantage all the time, that you would not want to remove. Then built on this are more complex types of speculation, in essence the complexity went up with time and processor sub family type.

Whilst Meltdown issues could and by now should have been fixed in Intel chips or in OS CPU type detection and software (with performance hit) Spector is a different "kettle of fish". As ARM noted some of the issues can be cured by removing certain types of speculation, others are more complex. However some are low probability of use, thus removing them has little impact on performance.

As ARM has indicated the addition of a tagging mechanism to remove speculation could be added to the instruction set, however the question arises as to if the compiler can work out where and when to tag, arguably the likes of byte code interpreters and certain types of language (not C and Co) would make this somewhat easier.

But... to get best effect the developers of the compilers and interpreters would need detailed knowledge that most processor design companies would regard as significantly proprietary.

For those who want to know a little more,

https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability/download-the-whitepaper

Clive RobinsonMay 16, 2019 4:01 PM

@ Nick,

Do you think these attacks will be limited to CISC or will people start finding the same things in RISC chips?

Speculation, whilst using the instruction set to determine it's next actions, is effectively at a high level view independent of the nature of the instructions.

Likewise there are very few true CISC CPU's these days in the same way there are few von Neumann CPU's either (microcontrolers are another subject). Thus CISC systems are in effect a wrapper around the likes of the "split cache" version of the modified Harvard architecture.

So CISC is effectively RISC Harvard architecture underneath and subject to any RISK issues.

The Flower of MarxismMay 17, 2019 4:41 AM

Modern processors already have gone for low-power, low-speculation multicores rather than massive speculation/dataflow. Branch prediction, BTBs, pipelines, in-order superscalar and caches/TLBs are presumably still critical to reasonable performance.

I assume the key in this case is to not share processor state between different entities. Flushing the processor state at a context switch might not be enough since you also have various caches and buffers. Perhaps coming system generations will require reserved cores and reserved portions of caches to combat these leaks, basically a 'stiff' version of virtualization. Unclear if that solves the whole problem though.

Might be worth monitoring processes and systems to see if there is odd cross-process activity too. If so, optionally turn the node into a honey pot or something.

Clive RobinsonMay 17, 2019 2:58 PM

@ The Flower of Marxism,

Modern processors already have gone for low-power, low-speculation multicores rather than massive speculation/dataflow.

Some, have gone "low-speculation" yes, but by no means all.

As I noted the various types of speculation are if you like "layered" with time. The easy gains first, but eventually Marketing "Specmanship" got in on the game, with what were in effect rigged tests that gave way more weight to some speculation advantages than were ever deserved.

I've not done it for a while, but the correlation between "specmanship features" and "security vulnerabilities" in software used to be quite clear in the past when you did a little research. Thus I suspect the same may be true of hardware.

As I've mentioned on other threads,in the past the future of computing is "massively parallel" from the chip level all the way up to glob spanning networks.

However the observation that still holds that "software developers are mainly sequential thinkers" still holds. Worse OS and other software support for parallel processing is to be honest more than a little ropy. Task switching can as interupt processing has shown been a very lightweight process, yet a glance around modern systems would suggest it is a task of Herculean proportions.

Whilst I would be more than happy to be amongst the first to put my hand up to say there could be a lot more and better hardware support for it, the real problem is still in what is software.

Some years ago this blog had discussions about using very very light processors (8/16bit logic 32bit or more arithmetic on some cores) with large register or tightly coupled very very local memory and have not just 2^5 cores on a single chip as we are seeing these days but more like 2^10 or considerably more. At the time the available real-world data suggested that there would be significant benifits including those of security and availability. That is "micro-tasks" running on lightweight CPUs was a direction we should be looking in.

It was mentioned that Chuck H. Moore of GreenArray with his Forth Array Stack Machine chip had done this but had been plagued by patent dispute litigation, which might account for the low take up of such technology.

However I suspect the real issue with the take up of massively parallel technology aside from the "sequential thibking" issue is "legacy code" that "has to be used". If you look at say MicroSoft's OS various security vulnerabilities have shown that underneath the graphical froth and applications little has changed from Win2K and even in some cases NT4... Whilst the assembler code might be 64bit not 32bit any longer, most of the algorithms, protocols and internal standards realy have not changed.

The Flower of MarxismMay 18, 2019 3:47 AM

As I noted the various types of speculation are if you like "layered" with time. The easy gains first, but eventually Marketing "Specmanship" got in on the game, with what were in effect rigged tests that gave way more weight to some speculation advantages than were ever deserved.

The sea change was with the Intel 'power wall' presentation, I believe. After that, the main research topic was power envelope, not speculative execution.

Some years ago this blog had discussions about using very very light processors (8/16bit logic 32bit or more arithmetic on some cores) with large register or tightly coupled very very local memory and have not just 2^5 cores on a single chip as we are seeing these days but more like 2^10 or considerably more. At the time the available real-world data suggested that there would be significant benifits including those of security and availability. That is "micro-tasks" running on lightweight CPUs was a direction we should be looking in.

You seem to be from the UK, so Occam might perhaps also ring a bell? Arguably, a limited form of this model has snuck in with the GPUs instead, which furthermore seem to be getting less and less SIMD as the years go by. (It still seems unlikely they would go full MIMD.) I have no particular insights into GPU security though.

Clive RobinsonMay 18, 2019 6:50 AM

@ The Flower of Marxism,

You seem to be from the UK, so Occam might perhaps also ring a bell?

Yes, a follow on to Wirth's Pascal frm the 1970's and 80's. Occam[1] was designed at Bristol based Inmos, with input from Tony Hore. more famous for it's Transputer chips with their high speed interprocessor links, that most remember Occam with.

However the Transputer was an unusual design, and kind of was the first single chip with speculation in it's architectutre. It was heavily microcode driven and though identified as a RISC processor by some, that interesting microcode system and the complex instructions and data speculation it alowed put it rather more firmly in the CISC camp.

[1] Occam is actually named after the rule "Occam's Razor" from English based Philosopher William of Okham, a place near Surrey, I used to know fairly well. However Occam is now in that expanding collection of computer languages I have used but now can not remember. However it used the same sort of white space deliminating of code blocks we now see in Python.

wumpusMay 18, 2019 8:10 AM

@Nick (CISC vs. RISC)

These attacks are all based on Simultaneous Multi-Threading (hyperthreading in Intel marketing). As far as I know, no ARM chip uses this (when they get around to it, they will be aware of Intel's blunders). IBM uses it extensively, but I doubt that many IBM Power Servers run untrusted code (especially along code that must stay secure).

Thus Specter has been a *mostly* Intel thing, with AMD requiring updating for spectre variant V4, DSS. Note that some ARM might be affected, but that seems highly theoretical without SMT.

The reason that these are largely SMT issues is that if you have a thread executing on a CPU and the target process is executing on the same CPU, you can repeatedly hammer the CPU with your attack and keep pulling information about the target process. If you don't have such a option (no SMT), you can only attempt to pull all the data left after a process switch. This doesn't appear to have enough bandwidth to bother making the attack.

One slight advantage Intel has (which may have been decided after Spectre was revealed to them) is that many CPUs are market segmented via turning off SMT. This used to be pretty clear by labeling (i5 chips didn't have it), but has long since been difficult to determine on laptops (you had to google the SKU, Intel wouldn't let advertisers admit that some i7 laptops had only 2 cores) and they've broken the pattern on the last generation[s?] of chips.

Almost all AMD chips maintain SMT, with only the lowest end chip lacking it.

Security SamMay 19, 2019 6:29 PM

It seems that crooks and nannies
Are hiding in nooks and crannies
And the latent hardware Trojans
Are hiding behind Intel slogans.

fishMay 19, 2019 9:05 PM

Thankfully these bugs are relatively easy to mitigate if you update your microcode and your kernel to make use of a modified instruction. It's not perfect though because it still requires SMT to be disabled and the MMU page tables can be leaked no matter what, which makes rowhammer easier to exploit.

C U AnonMay 22, 2019 4:01 PM

@ Cynthia Kenner-Brower,

it contains no links to source info

The same for your comment above,

is a complete bummer and waste of time to those interested in security issues,

The same for your comment above,

This is a crap blog with no true to source information, it contains no links to source info and opinions not related to topic.

You've provided no true anything as for "not related to topic" well how do I put it politely,

    Your comment is certainly "not related to topic" in any way shape or form.

Such was the style of your comment I had a quick search for the name you use and security related sites...

Guess what it appears that name has only been used twice before for inane comments on the Krebs site with nothing of technical merit, just swipy snippy irrelevences, just as above. Even SWJs put on a better performance.

As they so sarcastically say in the US and with such delightfully full on insincerity,

"Have a nice day".

Leave a comment

Allowed HTML: <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre>

Sidebar photo of Bruce Schneier by Joe MacInnis.

Schneier on Security is a personal website. Opinions expressed are not necessarily those of IBM Security.