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

41–50 of 406 posts

Re: Hertzbleed Attack

#41

Post by JulianWasTaken »

bob1029 wrote: post #14

Something about this doesn't bother me as much as other side channels. To me, this reads like trying to predict the presence, make, model & operational schedule of someone's washing machine just by observing how fast their power meter spins over time. Unless you have an intimate awareness of all of the other power consuming appliances, as well as habits of the homeowner, you would have a hell of a time reaching any m…

I would claim to know less than nothing about what's happening here, but to press a bit on the analogy -- aren't there workloads where clearly you're going to be more sure about what's happening? E.g. consider a bastion host proxying SSH connections into an environment. If you can observe the power meter on that laundry machine, you're much more likely to know what's using the power, no? (Especially so if the bastion isn't used flatly throughout the day).

Re: Hertzbleed Attack

#42

Post by phamilton »

staindk wrote: post #32
gpm wrote: post #15

Earlier quoted context omitted.

> since those tend to run at a sustained max anyway Really? I've never been on the cloud-provider side of cloud computing, but every application I've developed that ran on the cloud was rarely if ever running at a sustained maximum of the resources allocated to it. We always wanted a buffer to be able to absorb load spikes and users performing unusually expensive actions.

I think this means you were paying for the over-provisioning i.e. paying for a full CPU or baremetal server? "The Cloud" is all about vCPU - "2 vCPUs" feels somewhat standard for a base-tier VPS... and 2 vCPUs means "2 virtual CPUs" or rather "roughly equivalent to 2 CPU cores" I think. I understand that jargon to mean they are always cramming 11 x 2vCPU clients onto 20 physical cores.

Nah, vCPU is generally just hyperthreading. See https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/cpu-opti...

So you get 2 vCPUs per core.

Re: Hertzbleed Attack

#44

Post by bombcar »

gpm wrote: post #15
api wrote: post #3

Earlier quoted context omitted.

> What can you do about it? Nerf your CPU performance by disabling "turbo boost" or equivalent. Should you do it? Probably not unless you're particularly vulnerable (journalist, human rights activist, etc.) The most likely to be targeted (and probably easiest to target) systems are probably cloud hosts. This might be an argument for disabling frequency scaling and fixing clock speed on cloud VM hosts or bare metal se…

> since those tend to run at a sustained max anyway Really? I've never been on the cloud-provider side of cloud computing, but every application I've developed that ran on the cloud was rarely if ever running at a sustained maximum of the resources allocated to it. We always wanted a buffer to be able to absorb load spikes and users performing unusually expensive actions.

Dynamic scaling involves bringing the CPU frequency down but not off - you can get almost as much power savings for some loads by using the old HLT instruction, so your CPU/core is either at full speed or basically off.

Re: Hertzbleed Attack

#45

Post by zhdllwyc »

bri3d wrote: post #13
tootie wrote: post #6

I'm mind-blown at this vuln being exploitable remotely. How is that possible?

The paper is pretty good and does a great job explaining this: Basically, P-state / frequency governor side effects cause "constant-time" implementations of some algorithms like SIKE not to be constant time anymore - because in reality, these implementations were never "constant-time" but rather "constant-cycles" and with clock speed changing, so does the observed wall-clock time. Once this observation is made and th…

Thank you for enjoying reading our paper!

Re: Hertzbleed Attack

#46

Post by ceeplusplus »

staindk wrote: post #32
gpm wrote: post #15

Earlier quoted context omitted.

> since those tend to run at a sustained max anyway Really? I've never been on the cloud-provider side of cloud computing, but every application I've developed that ran on the cloud was rarely if ever running at a sustained maximum of the resources allocated to it. We always wanted a buffer to be able to absorb load spikes and users performing unusually expensive actions.

I think this means you were paying for the over-provisioning i.e. paying for a full CPU or baremetal server? "The Cloud" is all about vCPU - "2 vCPUs" feels somewhat standard for a base-tier VPS... and 2 vCPUs means "2 virtual CPUs" or rather "roughly equivalent to 2 CPU cores" I think. I understand that jargon to mean they are always cramming 11 x 2vCPU clients onto 20 physical cores.

No, 2 vCPUs is 2 logical threads, which is equivalent to a single physical core on x86. So yeah, they are cramming 11 x 2 vCPUs onto 20 physical cores. In fact, it's more like 20 x 2 vCPUs.

Re: Hertzbleed Attack

#47

Post by jessermeyer »

api wrote: post #3
MrWiffles wrote: post #2

Brilliant approach, really. Never occurred to me to try something like this! Are you affected? Very likely. What can you do about it? Nerf your CPU performance by disabling "turbo boost" or equivalent. Should you do it? Probably not unless you're particularly vulnerable (journalist, human rights activist, etc.) One thing I found interesting that may get changed later, so I'm documenting it here, is in their FAQ they…

> What can you do about it? Nerf your CPU performance by disabling "turbo boost" or equivalent. Should you do it? Probably not unless you're particularly vulnerable (journalist, human rights activist, etc.) The most likely to be targeted (and probably easiest to target) systems are probably cloud hosts. This might be an argument for disabling frequency scaling and fixing clock speed on cloud VM hosts or bare metal se…

There's so much variation (read, noise) intrinsic to response times for network requests to be satisfied on most cloud hosts anyway that I'm very skeptical about any practical attacks being made in the short term.

Re: Hertzbleed Attack

#48

Post by 1MachineElf »

Interesting that the mitigation is to turn off Turbo/Precision Boost.

Four or five years ago there was an an article submitted here (I wish I could find it) about a developer who keeps a machine with Turbo Boost disabled specifically because it seemed to interfere with their performance testing. By keeping it disabled they were able to eliminate a number of factors that prevented them from getting consistent results. It sounded like they preferred this approach for working on optimizing their code.

I am not pointing this out to disparage this performance boosting feature, only calling it out as a point of interest

Re: Hertzbleed Attack

#49

Post by hinkley »

I suspect what we are seeing in the last few years is the slow death of purely symmetric multiprocessing. At the end of this I wonder if we'll see processors with one or two cores dedicated to cryptographic primitives, where the ALU has a fixed IPC, the core has a very limited number of clock rates, and the caches are sized to prevent eviction when running common cryptographic algorithms.

Re: Hertzbleed Attack

#50

Post by sneak »

cylon13 wrote: post #9
leephillips wrote: post #4

My first highly amateur idea was to modify the frequency scaling algorithm with some randomness. How stupid is my idea?

Any noise strong enough to have a good chance of hiding the signal would completely defeat the benefit of having dynamic frequency scaling in the first place, I think.

Except that the processor can be doing other work during artificially induced noise delays, something not possible with delays introduced by lower mean frequency.
Post reply on HN