ARM TrustZone Hacked By Abusing Power Management (acolyer.org)

"This is brilliant and terrifying in equal measure," writes the Morning Paper. Long-time Slashdot reader phantomfive writes: Many CPUs these days have DVFS (Dynamic Voltage and Frequency Scaling), which allows the CPU's clockspeed and voltage to vary dynamically depending on whether the CPU is idling or not. By turning the voltage up and down with one thread, researchers were able to flip bits in another thread. By flipping bits when the second thread was verifying the TrustZone key, the researchers were granted permission. If number 'A' is a product of two large prime numbers, you can flip a few bits in 'A' to get a number that is a product of many smaller numbers, and more easily factorable.
"As the first work to show the security ramifications of energy management mechanisms," the researchers reported at Usenix, "we urge the community to re-examine these security-oblivious designs."

Comments

Every time

[DontBeAMoran]

Every time I hear about security, viruses and hacks, it's done via "opcodes", "registers" and "bits". Isn't it time we design more secure processors without these flaws?

Re:Every time

[elrous0]

Better yet, don't name your product with a name that can later become ironic, like "TrustZone." Try naming your product "ShitStorm" or "ClusterFuck" instead. That way, when it gets hacked or turns out to be buggy as hell, you can say "What did you expect? We told you so upfront."

Easy fix

[Anonymous Coward]

Don't allow non operating system code to muck with the system clock. Problem solved. Why would this functionality ever be exposed? This is something that non-OS code should NEVER be able to do.

You're kidding right?

[Ayano]

These Goldilocks voltages will vary by small margins.. too small to be accurately predicted for an actual attack.

TFA tries to make the argument that this physical hack can be done remotely despite the highly controlled conditions by relying on the power and energy management utilities...

Now i've got news as an embedded developer, that sh*t isn't accurate for anything this sensitive.

Re:You're kidding right?

[Anne Thwacks]

This is the same, or very similar, to an Intel bug described about a month ago:

The issue in both cases is either:

a) The device can be set to operate under conditions that are known to cause it to be unreliable (be out of spec)

b) The device fails to operate reliably when operated within spec

If it is (a) then perhaps the manufacturer should test devices more thoroughly - and then blow fuses to limit operation within spec. If it is (b) the manufacturer should test the devices more thoroughly.

You may know that (eg) Intel sell processors "locked" to prevent over clocking. This prevents (a). It obviously fails to prevent (b) either the manufacturer chose not to lock the device as (or the buyer chose not to buy locked ones) and the suer was "free" to use the devices out of spec, or the article describes devices where the tests were inadequate.

In reality, device performance is not consistent within a batch, and devices are sorted for performance - hence processors with different speed and power options. This has been true since the beginning of TTL. As devices have higher part count (see Moore's law) they have a higher probability of failure - since there are more failure modes, there is a much higher time-to-test. Time to test maps directly to device cost. Because time-to-test adds to cost, semiconductor devices are not tested 100%*: some parameters are, and others are only sampled to ensure that the tests are identifying the duds. The problem here is that the parameters tested by sampling may not be as reliably characterised as they are believed to be. If you assume that (for example) all static ram cells in the chip have essentially the same logic levels and speeds within a certain margin, and that margin has a wider spread between devices under circumstances that have not been identified, then testing some sample registers won't tell you that others are not reliable on chips with this unknown and unidentified problem.

Complexity does not scale linearly with transistor count - it is partly that, but it also scales with number of modules, module complexity, and number of interfaces between modules (hardware equivalent of API's not API instances). A more complex CPU has more of all three of these factors. Any way you look at it, a more complex chip will be more likely to fail in modes that are hard to identify.

About 15 years ago, I was part of a team that identified a problem in a CPU of fairly low complexity caused by data leakage between pipeline stages in a processor used in safety critical applications (AFAIK, no one actually died as a result of these failures). These failure modes are very hard to find. This one took about a man-year of very expensive engineers using very expensive equipment.

I predict that Moore's law will eventually be hit the Thwacks Barrier: Processor complexity will reach the stage where a processor cannot be adequately tested within a timescale that makes it worth producing.

I therefore hereby, formally pronounce that testability will be the barrier that ends Moore's law.

*Some /. users who are old enough to afford lawns may recall the national Semiconductors Mil-spec scandal: devices were sold as 10% tested when in fact they were only sampled, because the failure rate was "very low". No Aircraft carriers or space rockets were actually lost, but crimes were found to be committed anyway.

Re:Would the Rust programming language help?

[radish]

Not in this case. Rust (and similar programming approaches) prevent accidental interference between threads (of the same application) at the code execution layer - i.e. they prevent bugs due to programming errors. This attack is happening at the hardware level - the threads in question could be completely different applications and could be written in any language.