Schneier on Security

Clive Robinson • May 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.

Clive Robinson • May 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.

Clive Robinson • May 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.