Timing Attacks

[1] https://blog.cr.yp.to/20190430-vectorize.html

The page states that *all users* should disable all dynamic clock states and that all OS creators should do the same by default. That's very different than the very obvious info you just shared and in my opinion extremely over the top. What attack scenario do you think *users* would be targeted with?

Edit:

Just to be clear, if you store state secrets, are a cloud provider or otherwise hosts services that could be targeted by hertzbleed, by all means gimp your CPU if your research tells you that it is important.

There's just no reason to do so for the normal user and I think if you are in the class of people that need to secure something like that, it's narcissistic to believe they need to read the rant-ish site the OP posted to realize it.

It is also fascinating that stability on overclocks is often not the same sort of consideration as it once was. It once was the case that overclocking was limited mostly by whatever the critical path in the processor was, where trying to go too fast meant violating the setup time for a latch or register.

That does technically happen these days too, but the fix is to increase vcore voltage, which allows for shorter setup times basically by way of being faster at charging the parasitic capacitors to the threshold voltage. But this has downsides. In certain configurations this voltage can lead to greater silicon degradation over time. This is especially true if you are running above the designed max voltage. That said recent processor designs tend to have a lot more critical path headroom than old processor designs, often allowing a pretty significant overclock without even touching the voltage, but there will be a limit.

But increased voltage or even increased frequency alone means greater heat production, and there is a practical limit of how much heat you can remove in a unit of time with normal methods like air or water cooling. Go too high, and the heat can start to damage things, or more likely the processor's internal temperature monitoring circuits will command immediate poweroff from the motherboard. Of course, many coolers won't even reach these limits, meaning that you can often solve this by upgrading cooling. And obviously active cooling techniques like liquid nitrogen can largely eliminate this as a bottleneck of interest. (Although there would be a limit even for that scenario, the input power limit will occur first).

The last bottleneck is stable power delivery. There is a limited number of power pins, each with a bottleneck of current they can stably supply. The bottleneck may be PCB traces (indeed, for AMD, PBO compatibility requires motherboards to use bigger traces than are normally mandated for the processor, to allow for greater current), the pins, or even what the VRMs can supply. The VRMs will have a limit in both how much current they can supply, but also in how quickly they can respond to changes in current draw. Trying to pull too much can result in voltage instability, which can damage things (especially if reduced load causes voltage to swing too high).

So there is plenty of room for potentially degrading a processor if you are trying to eek out the maximum overclock you can get. But there is also in most current designs plenty of room for some overclock without having to get things near the limits, which is where you really risk degrading things. After all, processors are self overclocking themselves, which is what boost clock rates really are, and the default enabled overclocking tend to be pretty conservative in terms of how close to the limits they are willing to go. Even AMD's precision boost overdrive 2 automatic overclocking feature remains more conservative than many people are when manually overclocking. I'd wager that PBO2's limits are chosen such that no meaningful degradation is likely to happen, but merely not having nearly as much safety margin as they want to have on a default enabled feature.