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

Hertzbleed Attack

hertzbleed.com

Post reply on HN
Print view View original

191–200 of 406 posts

Re: Hertzbleed Attack

#191

Post by _0w8t »

ancientsofmumu wrote: post #188
_0w8t wrote: post #180

Earlier quoted context omitted.

On MacOS Low-Power mode in the Power section of system settings disables turbo-boost. On Linux echo 1 > /sys/devices/system/cpu/intel_pstate/no_turbo does the rick. Note that this is not the same as power-saving mode in Gnome settings. I have found that for heavy C++ compilation that lasts for many minutes the slowdown was about 20% on my ThinkPad X1 laptop. The big plus is that it made the laptop almost silent.

I think you're running into changing the governor mode here, which is a related but different part of the same ballpark. Modern Intel even has a "bias hint" allowed in addition to just a governor, where the user can help tell the power saving features what tradeoffs they prefer; power-saving mode is an additional limitation in conjunction with SpeedStep (or Turbo) P-state use; if the laptop is almost silent (no fans)…

It is Gnome Power setting dialog changes the governor. The above command just disables Turbo boost while allowing CPU to spend 100% of its time at the base frequency.

Re: Hertzbleed Attack

#193

Post by nickelpro »

ziddoap wrote: post #181
CamperBob2 wrote: post #143

Earlier quoted context omitted.

I haven't seen ANY side-channel timing attacks performed in the real world, but that doesn't stop the Security Theater crowd from costing us hundreds of millions of dollars and megatons of unnecessary carbon emissions by slowing everyone's CPU performance on the grounds that everyone's threat model is the same.

There are several (dozens) of papers showing the practicality of various timing attacks written by highly respected academics. Just because you haven't stumbled across an attack in the wild one does not somehow invalidate that there are practical attacks. Do you expect those who do carry out a successful attack to email you and let you know of their success? Or perhaps you think they'll exploit someone, and follow it…

None of the attacks are feasible in a trusted environment. If your code isn't running in an environment where other processes from untrusted sources are also running, these timing side-channels and their mitigations are irrelevant.

If an untrusted source gets shell access to your trusted platform/server/container and can run payloads, you're already screwed six ways from Sunday and the rest of the discussion is moot. It's security theater specifically because individuals and organizations following these blind mitigation recommendations don't assess the attack surface that's being exposed.

A school teacher wearing a condom is strictly speaking safer than the alternative, and yet someone should still be fired.

Re: Hertzbleed Attack

#194

Post by SilverBirch »

That first paragraph is perfect. It's an exact description of the concept and it's impossible to know whether this is a shower thought or whether 1,000 Intel engineers are going to spend the next 3 years added RNGs to their clock generation circuitry.

Re: Hertzbleed Attack

#195

Post by mgiampapa »

xoa wrote: post #155
BoppreH wrote: post #122

Earlier quoted context omitted.

> the attacker does in fact need to be able to get the targeted system to run something somehow Unfortunately that includes Javascript, and now that affects virtually everybody. Speculation: if you can find a Javascript call that uses protected keys, you might be able to extract secrets from that route.

OK, but can you walk me through the threat model here? This isn't a rhetorical question, it's easy to see how servers in general and shared hosting, colocated VMs etc in particularly might theoretically face a threat here, I'm just trying to get a better understanding of how GP would be correct for end user devices. The individual in question on the smartphone or computer specifically chooses to initiate a connection…

On most shared infrastructure would be even harder to exploit. In an ideal world you are sharing the infrastructure to maximize CPU and other resource utilization. When running workloads on VMWare for example, the best practice is to disable deep C states and not allow the CPU to dynamically scale down. This prevents all kinds of clock drift issues in guest VMs that expect a CPU cycle to be relatively constant.

Re: Hertzbleed Attack

#196

Post by Syonyk »

nickelpro wrote: post #193
ziddoap wrote: post #181

Earlier quoted context omitted.

There are several (dozens) of papers showing the practicality of various timing attacks written by highly respected academics. Just because you haven't stumbled across an attack in the wild one does not somehow invalidate that there are practical attacks. Do you expect those who do carry out a successful attack to email you and let you know of their success? Or perhaps you think they'll exploit someone, and follow it…

None of the attacks are feasible in a trusted environment. If your code isn't running in an environment where other processes from untrusted sources are also running, these timing side-channels and their mitigations are irrelevant. If an untrusted source gets shell access to your trusted platform/server/container and can run payloads, you're already screwed six ways from Sunday and the rest of the discussion is moot.…

> If your code isn't running in an environment where other processes from untrusted sources are also running, these timing side-channels and their mitigations are irrelevant.

And then you put 'mitigations=off' in your kernel command line and go on your way. I do it for all my BOINC compute nodes, because they literally have nothing sensitive on them.

But remember, L1TF/Foreshadow could reach across virtual machine boundaries. It's not just inter-process speculation that's a problem.

Re: Hertzbleed Attack

#197

Post by hindsightbias »

bobbylarrybobby wrote: post #51

Interesting, and seems like a natural followup to this side channel: http://www.cs.tau.ac.il/~tromer/papers/acoustic-20131218.pdf (RSA Key Extraction via Low-Bandwidth Acoustic Cryptanalysis), in which researchers deduced that the high-pitched sounds made by CPUs could leak the operations that GPG was performing to decrypt some encrypted content, and thus leak the private key. All you need is a microphone and the abi…

Surprising it took that long to look at sound when exploits on hw LEDs was a thing decades back.

Re: Hertzbleed Attack

#198

Post by SilverBirch »

mike_hock wrote: post #117

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…

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.

Re: Hertzbleed Attack

#199

Post by nickelpro »

Syonyk wrote: post #196
nickelpro wrote: post #193

Earlier quoted context omitted.

None of the attacks are feasible in a trusted environment. If your code isn't running in an environment where other processes from untrusted sources are also running, these timing side-channels and their mitigations are irrelevant. If an untrusted source gets shell access to your trusted platform/server/container and can run payloads, you're already screwed six ways from Sunday and the rest of the discussion is moot.…

> If your code isn't running in an environment where other processes from untrusted sources are also running, these timing side-channels and their mitigations are irrelevant. And then you put 'mitigations=off' in your kernel command line and go on your way. I do it for all my BOINC compute nodes, because they literally have nothing sensitive on them. But remember, L1TF/Foreshadow could reach across virtual machine bo…

Yep, and yet everyone in this thread seems to be rushing to kneecap their own performance, for what? My laptop isn't a GKE node.

There's a reason this CVE is classified as medium severity

Re: Hertzbleed Attack

#200

Post by Dwedit »

If you're already executing native code on the machine, you probably have the ability to read and write all the other memory of every other user mode process, so you don't need this to attack cryptographic keys stored there. This attack is more against secure enclaves.
Post reply on HN