Schneier on Security

Clive Robinson • January 22, 2018 1:02 PM

@ Bruce,

It seems to be Italian. Ars Technica speculates that it is related to Hacking Team:

There is a certain logic to that argument.

To many people “Hacking Team” effectively imploded for various reasons.

However whilst the company may have gone belly up the personnel are as far as I know alive and well. Thus they are most likely working in a not to disimilar line of work. Even if not they may have carried on in what is effectively their own time.

But even if that is not the case the collapse of Hacking Team, would have created the equivalent of a vacuum that others who knew them or even worked with them have decided to fill.

Clive Robinson • January 22, 2018 7:12 PM

@ Alyer Babtu,

Is it possible, with bounded resources, even in principle – secure computing over insecure systems (machines, networks), addressing confidentiality, integrity, and availability?

Long answer short “Yes to all”.

The only thing you can not defend against is a full insider attack at the full system level.

I’ve discussed this at length in the past on this blog with various long time contributors. I called it “Castles-v-Prisons” @Wael shortened it to “C-v-P” and in the odd place it is just “CvP” or “Prison architecture”.

One newer contributor @Thoth is designing a system around parts of the “Prison architecture”

And as we have found out a small team at University College London (UCL) many of whom came from the Cambridge Computer Lab have actually started building hardware you can buy based on @Thoth and my work (and no they have not acknowledged our “prior art” / work which is somewhat annoying).

As for,

Claude Shannon, please update yiour communication diagram.

Yes it’s been done by several people to not just show the effects side channels have, but passive and active attacks and adversaries. The thing is each addition in of it’s self is a Shannon Channel. Thus like the little old lady stating clearly to the learned gent whilst emphasizing with her umbrella handle “Sonney it’s turtles all the way down!” 😉

Clive Robinson • January 23, 2018 2:39 AM

@ Alyer Babtu,

Are there also any books, academic style treatments, etc. ?

There may be now, as the idea is finaly coming into vogue. However I have not checked in a while.

But at the time I was “cutting a trail” through what appeared to be virgin jungle as there was nothing in the contemporary literature that came up when I searched.

The nearest stuff was the unrelated memory taging ideas of the CHERI project over at Cambridge Computer labs, which still appears even now to be academic only. CHERI it’s self came out of another academic project “Capsicum” which looked into applying a hybrid capability model into the CPU architecture space. Supposedly allowing “fine-grained compartmentalisation within process address spaces”.

All whilst continuing to support current Unix software designs thus fell in the “Castle” domain. Which I had repeatedly pointed out was insecure by design (thus got heckled 😉

As such neither CHERI or Capsicum would not have provided protection against RowHammer or the recent Spector and Meltdown attacks. Because the latter two are a major failing of all “Castle” systems with cache timing side channels alowing “reach around” attacks. Whilst the former is a “reach down” attack from the ISA layer and above directly to a fault in the DRAM design. All three attacks are due to poor hardware design choices that try to be “to efficient” to get fractional speed improvments for “specmanship” reasons. Thus whilst the memory tagging might appear to be a hardware solution, it only applies to that thin security layer in the computing stack caused by the MMU that also gives the Virtual Memory capabilities. Which “reach around” and “reach down” attacks both bypass. Worse the MMU as curently used can not be used against “bubbling up” attacks that can alter the memory from any point in the computer stack below the CPU/MMU level. Thus realistically both CHERI and Capsicum were for protecting from software attacks above the CPU/MMU level which is CPU and up levels (this includes the Microcode level which converts the ISA instructions into the RTL hardware instructions as the back end of the instruction decode logic).

It has subsequently been pointed out to me via another “old Time” engineer, that some very early computer designs that pre-date “Vector Processing” to get “Super Computers” used some of the multi-processor tricks. That was there were a number of “Scalar” main Processing CPU blocks and I/O CPU blocks that communicated by a switching matrix or network. Both CDC and IBM had such designs (@Nick P has given some details on early CDC systems)

What I’ve been told is apparently Seymor Cray got his ideas for building massively parallel processing machines whilst working on the design of these CDC systems. But…

The “general knowledge” story is that Seymor Cray’s ideas went on into some of the early Cray systems and then Sun purchased the switching matrix ideas and put them into high end Sun systems such as the Starfire 10000. With that architecture still in the 12K, 15K and 20K Starfire systems that were still production when Oracle took over Sun in 2010 after Sun managment “dropped the ball”…

However it appears the real story is a bit more complicated and much more interesting (which should interest @Nick P amongst others).

It involves another highly inovative company, Floating Point Systems (FPS) in the quaintly named Beaverton, Oregon. FPS as their name suggested designed Floating Point Vector Units that were added to interger scalar CPU systems such as DEC Vaxen to give a very significant performance boost. At some point the story goes they sold their switching matrix idea to Sun… However it appears it may have been much more of a “technology swap”, because FPS went on to use Sun Spark station 2 ECL scalar CPU core designs in combination with their Vector Floating Point unit and a matrix switch chip in the Clark Masters design of CPU core for their FPS-500 parallel Vector processor system in the late 1980s.

When FPS got into financial troubles –as most Super Computer manufacturers did– Seymore Cray bought FPS and the FPS-500 unit became quickly redesigned –still using the ECL Sun SPARK CPU– into what became Cray’s Symmetric multiprocessor (Cray S-MP) system which became a semi independent division of Cray under Clark Masters.

When Cray followed the trend of super computer manufactures and got into financial troubles it was purchased by Silicon Graphics International (SGI) and the S-MP division was sold to Sun. Sun had at the time the financial resources to allow Clark Masters to implement the latent features of the original FPS-500 / Cray S-MP and the original Starfire 10000, which gave the 12K / 15K / 20K Starfire systems.

Although Sun nolonger produced SPARC chips (Fujitsu had taken over that) Sun Fire systems based on SPARC were in production up until 2010. Due to some very strange goings on in Sun over SPARK-v-Intel hardware Sun just like preceading Super Computer manufacturers got into trouble and were bought out much to many peoples supprise by Oracle.

Intel x86-64 based machines were manufactured and marketed under the Sun Fire name until mid-2012, when Oracle stopped using the Sun Fire brand altogether.

What became of the Clark Masters matrix ideas is unclear. In 2016 Fujitsu anounced they were moving from SPARK to ARM.

As for Clark himself, he was Chairman and President of Sun Microsystems Federal for a while, but in late 2007 he became President and Chief Executive Officer of Astute Networks, Inc. Since 2012 amongst other things he is Senior Vice President, Hana Cloud Computing. Maybe one day soon he will tell his side of the story.