News for hackers. Stuff that matters.

A comment on Hertzbleed Attack. Parent comment

Re:Hertzbleed Attack by sterlind on Wednesday June 15, 2022 @01:18AM (#31749391)
unless you do something special, a lot of interrupts are handled by CPU 0. there's techniques like Receive-Side Scaling to balance this load across the cores but that's specific to NICs.
[ Parent | on HN ]
Re:Hertzbleed Attack by robocat on Wednesday June 15, 2022 @02:05AM (#31749639)
Is that because CPU 0 tends to be scheduled by default? Or is that because the CPU usually uses core CPU 0, and Linux schedules to different cores?

Redhat Linux docs[1]:

The /proc/interrupts file lists the number of interrupts per CPU per I/O device. It displays the IRQ number, the number of that interrupt handled by each CPU core, the interrupt type, and a comma-delimited list of drivers that are registered to receive that interrupt.

The default value for smp_affinity is f, meaning that the IRQ can be serviced on any of the CPUs in the system. To view use cat /proc/irq/32/smp_affinity for interrupt 32 as example. Setting this value to 1, like echo 1 >/proc/irq/32/smp_affinity, means that only CPU 0 can service interrupt 32.

[1] https://access.redhat.com/documentation/en-us/red_hat_enterp...

[ Parent | on HN ]
Re:Hertzbleed Attack by bayindirh on Wednesday June 15, 2022 @01:48AM (#31749530)
However, I can pin a VM to far away cores to CPU0 (e.g. socket 3, cores 20-23), hence isolating it from all the interrupt handling, and attack that VM instead, at least in theory, no?
[ Parent | on HN ]