Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

X86 is a high-level language

blog.erratasec.com

Post reply on HN
Print view View original

31–40 of 125 posts

Re: X86 is a high-level language

#31

Post by matthewmacleod »

chaosphere2112 wrote: post #22
matthewmacleod wrote: post #18

Earlier quoted context omitted.

That's not an effective technique, unfortunately. You still end up leaking timing information. Lets say you add a small, random sleep after each operation – this still leaks information, as the delay can be averaged out over multiple runs. A fixed sleep after each operation is no use either, for obvious reasons. One approach I've seen is to break time into discrete quanta – for example, you could guarantee that every…

What if, instead of a random sleep, you have a defined period of time for a function to take– you take a clock reading at the start and end of your execution, and sleep the remainder of the execution time?

The problem there is that sleeping alters the performance characteristics of your system. If an attacker submits multiple requests simultaneously, it would be possible for them to determine if you were actually working, or just sleeping - and you're back to leaking.

Sure, every confounding factor makes it more difficult to extract information. But there are many effective techniques for doing so, and we keep getting better at using them.

Re: X86 is a high-level language

#32

Post by kazinator »

na85 wrote: post #20
kazinator wrote: post #17

"high level" doesn't refer to how it is implemented. Even a RISC instruction set can be implemented by, say, either some very slick silicon gates, or by an emulator written in Javascript. The existence of the Javascript emulator doesn't make the RISC instruction a high level language, on the grounds that an instruction like "ADD R1, R2, R3" triggers a complicated traversal within the Javascript code. The "level" of a…

I think that's the author's point: x86 is now a significant abstraction from the actual details of execution.

But what x86 can express hasn't changed; just how it performs.

An abstraction never includes the details of execution; abstraction is that separation itself! A piece of 80386 code running on an 80386 is no more or less abstract than the same piece of code on a Core i7. They agree in their external effects, like what inputs are loaded from memory, and what result is written.

The fact that EAX is renamed to different internal registers or whatever isn't really "high level": not "high level" in any way that helps the programmer express something. It just changes the performance.

It's not high level the way that, say, "reduce + list" is higher level relative to "for (total = 0; i = 0; i (Exceptions are situations where programs do certain things; e.g. self-modifying code needs to tackle instruction caches on one implementation, but not another. That's where the abstraction "leaks".)

Re: X86 is a high-level language

#33

Post by JohnBooty »

If "constant time" programming isn't possible, could crypto code thwart side channel analysis by moving in the "other" direction - adding random amounts of spurious computation?

If I can't hide the work my code is doing by making it take the same amount of time (and use the same amount of power) no matter what I'm doing, seems like I could obscure it by adding a random amount of work - so that even the same "real" crypto workload would use varying amounts of power on subsequent runs.

Although I guess that would only be a partial solution at best. If an attacker could monitor many runs of the same "real" workload, some simple statistical analysis would still tell you some things.

Re: X86 is a high-level language

#34

Post by [deleted] »

jstarks wrote: post #28

The author's conclusion that side channel attacks are unpreventable because x86 instructions execute in a variable amount of time does not follow. Side channel attacks that rely on variable instruction timing rely on _content-dependent_ timing. For example, the time spent for a mov from a memory location does not depend on the contents of the memory, but it does depend on the address of that memory. If that address i…

[deleted]

Re: X86 is a high-level language

#35

Post by malka »

"Inside the CPU, the results always appear as if the processor executed everything in-order, but outside the CPU, things happen in strange order."

I think the words 'outside' and 'inside' have been swaped

Re: X86 is a high-level language

#36

Post by Animats »

na85 wrote: post #20
kazinator wrote: post #17

"high level" doesn't refer to how it is implemented. Even a RISC instruction set can be implemented by, say, either some very slick silicon gates, or by an emulator written in Javascript. The existence of the Javascript emulator doesn't make the RISC instruction a high level language, on the grounds that an instruction like "ADD R1, R2, R3" triggers a complicated traversal within the Javascript code. The "level" of a…

I think that's the author's point: x86 is now a significant abstraction from the actual details of execution.

That's true of all superscalar machines. That's what killed RISC. The original idea of RISC was one instruction per clock and a very simple CPU control section. Early MIPS CPUs realized that.

Then superscalar came to microprocessors with the Pentium Pro. It took 3000 engineers at Intel to design that CPU, but it did much better than one instruction per clock while still handling all the weird cases in x86 instructions. As the fabs improved, the Pentium Pro technology moved to the mainstream. The Pentium II and III were Pentium Pro architecture.

This killed the basic advantage of RISC. The "all instructions the same length" concept really killed it - it meant 2x code bloat. That meant bigger caches or worse cache performance. It meant more RAM and more RAM bandwidth or worse memory performance. The x86 instruction set, for all its faults, is compact.

For the crypto problem, the trouble is that modern crypto algorithms are not branch free. DES was. Vernam was. Rotor machines were. RSA and elliptic curve stuff, no. This is independent of the CPU architecture.

Re: X86 is a high-level language

#37

Post by xenophonf »

schoen wrote: post #19
tptacek wrote: post #3

Every major server ISA is, in this sense, "high level": the ISA is documented, but the microarchitecture isn't, and there are timing-relevant details known only to the manufacturers. Aciicmez famously demonstrated this with a timing attack on the branch prediction cache.

Any idea why the manufacturers haven't shown more interest in helping out crypto implementers? Surely timing attacks are a pretty prominent problem in microprocessor design circles by now.

There's a lot of fear surrounding in-hardware crypto primitives. See for example:

http://arstechnica.com/security/2013/12/we-cannot-trust-inte...

I personally would be very leery of OpenSSL relying on RdRand or AES-NI.

Re: X86 is a high-level language

#38

Post by [deleted] »

fchollet wrote: post #12
yxhuvud wrote: post #6

I wonder if introducing a sleep that is longer than the computation could conceivably take would work to solve (or at least make it a lot harder to defeat) the actual problem. The failure case where the computation actually is slow enough to matter could be detected and thrown away. This of course would require a fully async crypto lib..

How about random sleeps distributed so that the mean sleep time is always the same for every computation? (and much longer than any likely computation). timer.start(); computation(); time = timer.stop(); sleep(random_centered_on(mean-time));

[deleted]

Re: X86 is a high-level language

#39

Post by soup10 »

Yet another reason high-performance code will continue to be written in c/c++. Every abstraction layer from actual machine architecture severely convolutes the optimization process.

Re: X86 is a high-level language

#40

Post by mjhoy »

Animats wrote: post #36
na85 wrote: post #20

Earlier quoted context omitted.

I think that's the author's point: x86 is now a significant abstraction from the actual details of execution.

That's true of all superscalar machines. That's what killed RISC. The original idea of RISC was one instruction per clock and a very simple CPU control section. Early MIPS CPUs realized that. Then superscalar came to microprocessors with the Pentium Pro. It took 3000 engineers at Intel to design that CPU, but it did much better than one instruction per clock while still handling all the weird cases in x86 instruction…

> Then superscalar came to microprocessors with the Pentium Pro.

Hmm, but wasn't the PowerPC 601 superscalar?

Post reply on HN