Re:Hertzbleed Attack
by mgiampapa on Tuesday June 14, 2022 @05:20PM
(#31746242)
On most shared infrastructure would be even harder to exploit. In an ideal world you are sharing the infrastructure to maximize CPU and other resource utilization. When running workloads on VMWare for example, the best practice is to disable deep C states and not allow the CPU to dynamically scale down. This prevents all kinds of clock drift issues in guest VMs that expect a CPU cycle to be relatively constant.
[ Parent
| on HN ]
Re:Hertzbleed Attack
by angry_octet on Friday June 17, 2022 @09:31AM
(#31777874)
This is not about power saving, it is dynamically, on the granularity of individual instructions, balancing the thermal dissipation available across cores. When some cores are relatively idle (e.g. waiting on cache fill) it uses the available amps to run other cores at "turbo boost" frequencies.
For some single threaded code we force other cores to idle so that one thread can get maximum cache and maximum frequency. A similar approach could be used to minimise the power analysis signal.