Hacker News Reader

Comment by mike_hock | Hacker News Reader

Why do we never get proactive defense against this sort of thing? As with speculative execution, caching, out-of-order execution, dispatching instructions to multiple ALUs depending on availability, etc, it was clear from the get-go that in principle the timing can depend on the payload so in principle it can be a problem for crypto.

The need for constant time should have first class support on the language/compiler level, the OS level, the ISA level, and the hardware level. E.g. the processor could guarantee that the instructions of a certain section of code are executed at a constant rate, the OS could guarantee that the thread remains pinned to one core and the frequency fixed, and the compiler could guarantee that only branchless assembly gets emitted.

View on HN

This is engineering, there's a lot of things that could happen but don't, we don't all run ECC RAM either. The problem is that speculative execution is really good and if Intel didn't have it they would've been selling worse CPUs. And to be clear, it was about 20 years from the point where people were seriously publishing theories about speculative execution attacks to the point where it was a practical attack.

Think about how much benefit we gained during that time. And even then, anyone running in a trusted environment would rather have the optimization consequences be damned. Do you think HFTs patched their boxes to criple their perfomance? No.

Sure, now we know it's a problem we'll offer solutions for people who really need it. But it'll be a long while before the average person needs to think about this and in the meantime billions of people benefitted from better CPUs.

> we don't all run ECC RAM either

...because Intel placed profit above user's needs and choose not to allow ECC on desktops.

Similarly, many other things have been made insecure by plain greed.

The other way of looking at it is that a huge portion of the market is running non-ECC ram and it hasn't resulted in any measurable reduction of security or stability of operating systems worldwide. So maybe it really isn't necessary for your average user, and manufacturing ECC ram for users who ultimately don't need it would be just a waste(both financial and environmental).

> hasn't resulted in any measurable reduction of security or stability of operating systems worldwide

Except it did.

By how much?

More than zero.

> in any measurable reduction

How do we know that it didn't?

How many consumer OS crashes can be attributed to RAM errors?

How many corrupt files, strange bugs, or quirks can be attributed?

Google researched the topic over 2.5 years last decade and did find a notable amount [1]. "Bitsquatting" has also been seen in the wild in the past decade [2].

[1] https://static.googleusercontent.com/media/research.google.c...

[2] https://en.wikipedia.org/wiki/Bitsquatting

I stand corrected then. Thanks for the links.

I'll argue the opposing side. Can you imagine how little progress there would be if all CPU/Ram development were a government program?

The same government programs that funded almost all the initial research on semiconductors and early computers for the first 4 decades?

The programs who funded the research for telephones, lasers, aeronautics, satellites, CDs, fiber optics, GPS, GSM, LCDs using tax money?

I can imagine how little progress there would be if they didn't.

That's why it should be a concept known to all levels of the architecture so any mitigations can be applied topically and don't need to affect anything else.

Until consumers demand this as a requirement, it won't happen. Almost everyone would rather have a compiler/language/OS/ISA/CPU that's finishes faster some of the time, rather than one that finishes at the same time all the time. It would just appear (especially in benchmarks) to be slower for no apparent benefit.

Maybe we can introduce a new set of instructions that are guaranteed to be constant time, but good luck convincing the compiler/language/OS to use these slower instructions even if just for the code that is important for security.

And for this particular attack, constant time isn't even enough! You would need either constant power, or limit the frequency when running secure code (which again reduces performance).

Constant time comparisons take practically no time at all. I hardly see how it would noticeably reduce performance if software could command a CPU to lock to a low frequency for a certain period of time or when the sensitive code finishes, whichever happens first. The OS could track how often this happens and give a simple UI so that we can blame those applications that abuse it.

> Why do we never get proactive defense ... The need for constant time should have...

We got proactive constant time on a lot of cryptographic operations.

The problem is, it's not constant power.. and DFS provides a window by which you can make remote power measurements.

That wasn't proactive it was in response to earlier timing analysis attacks.

Discovering and reporting these flaws is proactive defense.

Simplest solution here is to implement the algorithm in hardware, with a new instruction that has all the security attributes. (Including resistance to power differential and timing differential attacks.)

Downthread: https://news.ycombinator.com/item?id=31745105

But this is inflexible.

True.

But did you want a microcode vulnerability? That'd make for another one of these awesome HN discussions...

Then start adding FPGAs!

Seriously, this has been talked about for ages now. If every platform had a good enough FPGA, it could be used for cryptography and/or to accelerate some specific computations. Abd without having a set of algorithms baked into the silicon, it would not make the device eventually obsolete as the world moves to better algorithms.

Not only has it been talked about for ages, Intel bought Altera and AMD bought Xilinx. One has to wonder and ask - why?

Edit: > it would not make the device eventually obsolete as the world moves to better algorithms

Ah there I found it. Makes sense to buy the FPGA manufacturers, so they devices still become obsolete and people buy their newer processors.

Reply on news.ycombinator.com