Security is always about raising the costs of breaking through security over what the value of what is being secured. If you find the page "over the top", it is not because the page is over the top, but because you don't have anything to secure that is in the cost range of the attacks being outlined. That's great. Personally, I at best have maybe one secret that is in that value range (and on the low end at that), and the vast majority of what I deal with day to day myself is not in that range. This is probably true for the vast majority of people reading this comment as well.
However, it is not true for everybody. When you're securing something very valuable, as some people do, those problems become a big deal. Some security researchers need to be working at that level, or people with those problems will just be helpless.
I have read all about this attack. I haven't touched any settings on my computer. It isn't a problem for me. But it is a problem for other people. You're just peering in on a world that you don't live in. It's kind of like asking "Who would ever need a bodyguard? Seriously?" Well, I can neither afford one, nor do I seem to particularly need one... but I'm not the only person or type of person in the world.
> If you find the page "over the top", it is not because the page is over the top, but because you don't have anything to secure that is in the cost range of the attacks being outlined.
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.
Most notably one of the authors first points is that overclocking leads to premature failure of hardware, which is neither correct nor relevant to security. Premature failure of hardware depends on operating temperatures and it's trivial today to overclock and substantially decrease operating temperatures for any knowledgeable overclocker.
I'm not versed in timing attacks so I don't really understand the implications there, so I'll defer to the authors expertise in the regard.
Overclocking can vary. People trying to get as the absolute fastest clock rates they can without the system becoming unstable will be trying to push the CPU as close.
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.
