Schneier on Security

Clive Robinson • November 15, 2018 3:54 PM

@ Otto,

If somebody finds a way to remove branches (and memory accesses) from software or a way to resolve them faster, then we can remove speculation (and caches) without losing unacceptable levels of performance.

They already have in a way. You increase the number and size of registers even more than Vector Processors and you use the very local memory that was used inefficiently for caching as local core RAM for both execution and data. You then strip your software down into “tasklets” that fit within those constraints. The CPU can thus be risk based and will run with upto a 10GHz clock. You can get quite a few on the same size chips Intel are currently using and if you get your parallel programing right it will do many tasks very efficiently.

The big problem is the so called “thin streak of sequentialness behind the key board” way to many programers think in series and many computer languages are designed to support that way of thinking… Even Intel know it’s a lost cause hence the number of CPU cores they stick on high end chips. Throw in a couple or sixteen FPGA’s as well and the current bottle neck would have been solved if not for sequential thinking…

Clive Robinson • November 18, 2018 4:18 PM

@ john doe,

On May 8, 1995, a paper…

It was not exactly new then either. Time based side channels had been known for some time before that. If memory serves Seymour Cray made comment on the subject when talking about some of his work (though it was not called “time based side channels” back then, that terminology kind of started in the 1970’s via Gus Simmons).

The supprising thing is realy how long it has taken to “exploit it”.

That is few security specialists had any kind of knowledge below the ISA level in the computing stack. They just kind of assumed it was all OK below, having worked at the microcode level, the RTL level and at the logic gate and below level, I was more than aware of issues. So like other hardware engineers “we knew” but “said little”. Amongst so many issues we tried to protect against what we thought was most likely, thus the reason parity checking on memory was a introduced to try to fix a “class” of issues. But most hardware engineers were only to aware of how badly designed tgings were, we knew DMA was a major security hole, as was dual processor “shared memory”, we just assumed the other side of the ISA gulf guys knew as well. Thus that the OS and compiler guys would use the MMU etc judiciously to mitigate…

At any point somebody could have not just worked out but published an exploit, it just did not happen, nobody gave the snowball the nudge. Now they have it’s heading down the valley getting bigger and bigger and is becoming a bit of an avalanche effect…

As my son is fond of saying “That’s the way it be Bro”…

Clive Robinson • November 23, 2018 8:18 AM

@ Wesley Parish,

From the El Reg article,

The findings are significant because while ECC was once considered a reliable method for thwarting Rowhammer-style attacks, it was thought to be theoretically possible to bypass the defense mechanism. Now an attack has been demonstrated.

In other words it was just a question of time… Because “The laws of physics alow”, and “Human ingenuity knows no bounds when the incentives are right for ‘hinky thinking'”…

The point about ECC, parity checking and similar “Error Detecting / correcting” codes is that like most other hashes they are not perfect, though they might be complex.

If you think about it, when you write a word to memory you write directly to the data bits cells, but with error detection and correction you also at the same time write to a logic circuit that “eventually” writes to the error check bits. Thus there is a write penalty to pay that with tricks can only “on average” be reduced.

Likewise when you read a word from “error check” memory you read directly from the data bit cells, that also go at the same time go along with the error check bits to a logic circuit that “eventually” produces a verification signal. It’s an even longer “eventually” when you add in correcting as well as,checking…

Thus as with “time” short cuts in the DRAM design, the error checking and correcting circuits are designed to make that “eventually” as short as possible to keep memory performance high.

When you do things like that without the right knowledge –which might not come along till later– then you are more likely than not to open up a security flaw (from “Security-v-Efficiency” issue). Which just leves the question of “Can somebody exploit it” which in this case is yes, but currently not as easy as it probably will get.

All of these “hiden” hardware issues that are poping up are not realy “hidden” more “forgoton” or “not much talked about” for ovet a quater of a century as I’ve mentioned before.

Believe it or not they actually go back over half a century to the design of “carry circuits” in adders, which are about the slowest instructions in the design of an ALU. Even today people are writting the occasional paper about the problems with “word wide carry” not just in ALU’s but MMU’s and even DMA controlers. All of which have interesting little “side channels” that can leak information or be abused in some way if checks are not put in to prevent them.

The problem with such checks is they also take time… so you end up with a Catch-22 type problem, where to go any faster you “should” add checks but that slowes things down again, takes up more real estate, burns more power, generates more heat etc etc for no “performance” benefit. Thus the “So why bother?” question gets asked, followed fairly shortly there after by the old “Aftet all, it’s only a theoretical risk” excuse…

As has been noted even the dumbest of chickens come home to roost…