The "Hertzbleed" vulnerability [LWN.net]

The "Hertzbleed" vulnerability

Posted Jun 14, 2022 20:54 UTC (Tue) by flussence (guest, #85566) [Link] (11 responses)

> You can prevent Hertzbleed by disabling frequency boost.

Oh, nothing to worry about then. I do that already because I've never seen a single measurable benefit from it on a Ryzen and it only increases peak CPU temps by 20°C. Highly recommend others give it a try, regardless of this week's alarmism.

Put `printf 0 >| /sys/devices/system/cpu/cpufreq/boost` in your startup scripts, or do the equivalent in a udev rule if you want to be fancy. Simple.

The "Hertzbleed" vulnerability

Posted Jun 14, 2022 22:15 UTC (Tue) by bartoc (guest, #124262) [Link] (2 responses)

On a desktop it doesn't really matter, but on a laptop it absolutely does. Also, 20C is quite a lot, that would make my fans somewhat more noisy (although already they are annoying because ryzen tends to fluctuate around in temperature a lot, so they throttle up for a very short amount of time before throttling back down, this is really an issue with the motherboard firmware though).

How much does this increase power usage? Like this sort of thing matters the most for servers/multitenant machines, and those definitely do want scaling.

The "Hertzbleed" vulnerability

Posted Jun 15, 2022 9:26 UTC (Wed) by eduperez (guest, #11232) [Link] (1 responses)

What @flussence is trying to say, is that *enabling* "frequency boost" increases the temperatures by 20C, and has no noticeable benefits on performance; thus, he is advocating to *disable* it. Also, notice that "frequency boost" is about (temporarily) running the CPU at a frequency higher than the baseline frequency; perhaps you where thinking about "frequency scaling", where CPU runs at a lower frequency, during periods of low load.

The "Hertzbleed" vulnerability

Posted Jun 15, 2022 19:21 UTC (Wed) by bartoc (guest, #124262) [Link]

I was indeed!

Comment fully retracted :)

The "Hertzbleed" vulnerability

Posted Jun 15, 2022 0:41 UTC (Wed) by jmclnx (guest, #72456) [Link]

For me it was

echo "1" > /sys/devices/system/cpu/intel_pstate/no_turbo

and no performance issues for me on a Laptop

I found that in the link below, interesting it is from 2019, but since I found out gamers do that in order to do something else to max their CPU out.

https://sleeplessbeastie.eu/2019/07/15/how-to-disable-int...

The "Hertzbleed" vulnerability

Posted Jun 15, 2022 1:04 UTC (Wed) by ccchips (subscriber, #3222) [Link] (3 responses)

I have Intel NUC 10, on Linux Mint 20. Where would I find that switch? There's no entry matching the one in your message. When I try to run your command as sudo, I get "Permission Denied."

The "Hertzbleed" vulnerability

Posted Jun 15, 2022 5:00 UTC (Wed) by devnull13 (subscriber, #18626) [Link]

Does this answer your question? https://forums.linuxmint.com/viewtopic.php?t=355295

The "Hertzbleed" vulnerability

Posted Jun 15, 2022 18:12 UTC (Wed) by flussence (guest, #85566) [Link]

I was under the impression that was the standard sysfs knob for it, but as others have pointed out, Intel does its own thing.

The "Hertzbleed" vulnerability

Posted Jun 24, 2022 3:05 UTC (Fri) by danielwagenaar (guest, #14814) [Link]

If you run

sudo echo 1 > /sys/whatever

only the "echo 1" is run as root. The piping to "/sys/whatever" is done by your shell using your regular user account. Hence the idiom

echo 1 | sudo tee /sys/whatever

which runs the "echo 1" under your regular user account, and lets the "tee" command copy the output out to "/sys/whatever" as root.

Hope that helps.

The "Hertzbleed" vulnerability

Posted Jun 15, 2022 14:34 UTC (Wed) by nye (subscriber, #51576) [Link] (2 responses)

> I do that already because I've never seen a single measurable benefit from it on a Ryzen and it only increases peak CPU temps by 20°C

If you can't measure a performance difference, you have something very wrong with one or more of your hardware, BIOS, and/or kernel - you should generally be seeing around 30% depending on the specific CPU.

I'd say maybe it's just not working at all, but that wouldn't explain the heat increase so there must be something more going on, eg you have bad hardware and it's increasing the voltage a huge amount in order to get a tiny boost. I had a 3700x which was absolute garbage so AMD is definitely producing some bad silicon, but even then the speed difference was meaningful; it's just that the temperature increase was wildly non-linear.

The "Hertzbleed" vulnerability

Posted Jun 15, 2022 18:10 UTC (Wed) by flussence (guest, #85566) [Link] (1 responses)

BIOS most certainly kicks rocks - it's a Gigabyte board. The normal max clock is 3800 without boost and something like 4400 with, but leaving it turned on doesn't improve life in any way for me while the downsides are immediately visible. If it's dud silicon then I can accept that, but I'd at least like it to last long enough to replace with a Linux-running M2 down the line :-)

The "Hertzbleed" vulnerability

Posted Jun 20, 2022 15:58 UTC (Mon) by eduperez (guest, #11232) [Link]

Going from 3800GHz to 4400GHz is a 16% increase, but only in CPU frequency, among a myriad of other factors that affect performance... it's probably imperceptible for many use cases, and not worth the cost.

The "Hertzbleed" vulnerability

Posted Jun 14, 2022 21:13 UTC (Tue) by jhhaller (guest, #56103) [Link]

From the name I thought it would have something to do with renting a processor and being incorrectly arrested for possessing a stolen processor, and being beaten by the police in the arrest process. But, I guess that only happens with cars, and perhaps only in the US.

The "Hertzbleed" vulnerability

Posted Jun 14, 2022 21:41 UTC (Tue) by pjhacnau (subscriber, #4223) [Link] (1 responses)

> Today's branded, logo-equipped vulnerability

It's been a while since I've seen a good vulerability logo . . . my Meltdown T-shirt is wearing out . . .

The "Hertzbleed" vulnerability

Posted Jun 14, 2022 22:40 UTC (Tue) by Henning (subscriber, #37195) [Link]

At least this one seems to be one that will stay relevant for quite a while, in comparison to heartbleed and others where there is not much to talk about after it was patched.
Spectre and now this hertzbleed feels like they will stay relevant. I just wish there was a good rowhammer logo to go with them.

The "Hertzbleed" vulnerability

Posted Jun 15, 2022 10:10 UTC (Wed) by wtarreau (subscriber, #51152) [Link] (8 responses)

Bof. Only practical on an idle lab machine to impress audience. Nice work regardless. With a bit of luck it will encourage CPU vendors to abuse less of the turbo frequency and to make the base and max closer to each other, or maybe depend less on too strict measurements.

Note that usually you can change the periodicity of the power measure using one MSR that's essentially used to divide it. It could likely be sufficient to smooth it enough so that nothing can be taken out of it even on an idle machine.

The "Hertzbleed" vulnerability

Posted Jun 15, 2022 13:16 UTC (Wed) by snajpa (subscriber, #73467) [Link]

could perhaps some randomization of that MSR be useful to thwart the attack? I guess it would need to be changed pretty often - I'm wondering whether the systick/scheduler interrupt would be enough + if it wouldn't be too costly...

The "Hertzbleed" vulnerability

Posted Jun 15, 2022 15:07 UTC (Wed) by Paf (subscriber, #91811) [Link] (5 responses)

But the attack isn’t measuring power usage. It’s measuring computation speed due to power level changes.

The "Hertzbleed" vulnerability

Posted Jun 15, 2022 16:44 UTC (Wed) by wtarreau (subscriber, #51152) [Link] (4 responses)

Yes, but the power level change happens after some cumulated usage.

The "Hertzbleed" vulnerability

Posted Jun 16, 2022 14:09 UTC (Thu) by developer122 (guest, #152928) [Link] (3 responses)

And, you don't actually need access to that MSR to perform the attack.

Attacker feeds in chosen tests, sets their watch.
Results come back, attacker checks their watch and notes the time.
Repeat until enough text+timing measurements have been taken to deduce the secrets.

Power consumption is only an indirect mechanism. Some computations take more power. Taking more power affects time because of CPU boost scaling. The attacker doesn't actually need to be able to measure power consumption directly.

This is *not* plundervolt.

The "Hertzbleed" vulnerability

Posted Jun 17, 2022 16:42 UTC (Fri) by wtarreau (subscriber, #51152) [Link] (2 responses)

I never said that the attacker needs to measure anything (beyond time). It's the CPU that does it and switches the frequency once a threshold is reached. The MSR I was speaking about allows to define the measurement period (in fact how much the value is smoothed). When you smooth it over tens of seconds, good luck finding a secret key based on frequency switch that happens 20s later! It will remain possible in the lab, by always computing the exact same key in loops with no external perturbations, and that's enough to write a paper, create a logo and a web site. But honestly, these days there's so much business turning any behavior into a security issue that it's about time we focus on *real* problems that allow to disclose *real* data from *real* systems. Note that I've even seen some reports saying "if I modify this driver this way I could find this so I think this driver is close to being insecure". That's too much of a theater.

The "Hertzbleed" vulnerability

Posted Jun 18, 2022 21:48 UTC (Sat) by Paf (subscriber, #91811) [Link] (1 responses)

Ahh, I see what you mean now - this is the MSR controlling the frequency adjustment itself.

But of course that basically means disabling high frequency power adjustments, so how bad is that?

The "Hertzbleed" vulnerability

Posted Jun 21, 2022 20:40 UTC (Tue) by wtarreau (subscriber, #51152) [Link]

It just takes longer to reach lower levels and to reach higher levels again after the stress ends.

The "Hertzbleed" vulnerability

Posted Jun 21, 2022 10:19 UTC (Tue) by eduperez (guest, #11232) [Link]

Yes, I would like to know how feasible is this attack in the real world, against a machine that is running something else than the proof-of-concept code, where the frequency scaling is constantly going up and down, and dozen of tasks have to fight each other for CPU time.

The "Hertzbleed" vulnerability

Posted Jun 16, 2022 8:52 UTC (Thu) by anton (subscriber, #25547) [Link] (4 responses)

The attack is against SIKE, not something more well-known, and a similar attack on SIKE has been discovered independently. This gives me some hope that most other "constant-time" cryptographic code is harder to exploit and that mitigations are not that hard. But of course, this was just the first attack, others might be coming in the future, and the paper mentions that another group has attacked AES-NI through a frequency side-channel (but required lowering the power limits, i.e., a privileged attacker).

Concerning mitigations, the need for constant power makes me think of ECL (a circuit design method), which achieves constant current by IIRC letting the current run through exactly one of two complementary lines. Can we achieve constant power by also performing a computation complementary to the one we want to perform, resulting in constant power overall?

The "Hertzbleed" vulnerability

Posted Jun 16, 2022 12:36 UTC (Thu) by hkario (subscriber, #94864) [Link] (3 responses)

> Can we achieve constant power by also performing a computation complementary to the one we want to perform

Yes, but it is counter opposed by the CPUs need to be power efficient. And it's not just power efficiency for the mobile, or high density computing, it's also so that it generates less heat, so that it can run at higher clock speeds longer.

The "Hertzbleed" vulnerability

Posted Jun 16, 2022 14:24 UTC (Thu) by anton (subscriber, #25547) [Link] (2 responses)

My idea was to add the complementary computation in software, only for the code that deals with these supersecrets, like cryptographic keys. But it's not clear to me whether we can do such complementary computations in software.

The "Hertzbleed" vulnerability

Posted Jun 18, 2022 21:51 UTC (Sat) by Paf (subscriber, #91811) [Link] (1 responses)

I think it would require an extremely detailed understanding of the exact energy properties of the specific math on that CPU - ie, I think what “complementary” means will depend on precisely what’s easy or hard for a particular CPU, ie, precise implementation details.

The "Hertzbleed" vulnerability

Posted Jun 19, 2022 17:07 UTC (Sun) by anton (subscriber, #25547) [Link]

Yes, that's what I would have expected. However, the present attack works across different CPU models, so apparently it uses some common property. A defense against this attack could also use that common property.