|
|
Subscribe / Log in / New account

The "Hertzbleed" vulnerability

The "Hertzbleed" vulnerability

Posted Jun 17, 2022 16:42 UTC (Fri) by wtarreau (subscriber, #51152)
In reply to: The "Hertzbleed" vulnerability by developer122
Parent article: The "Hertzbleed" vulnerability

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.


to post comments

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.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds