4 ms·

I was thinking about busy servers running mixed workloads. I would think that, with the CPU running a bunch of workloads on different cores, context switching,

I was thinking about busy servers running mixed workloads. I would think that, with the CPU running a bunch of workloads on different cores, context switching, etc, it wouldn't be a practical attack. Maybe that's incorrect. Mostly idle servers are a different story, obviously.

bayindirh 4y ago
Sometimes response critical VMs are pinned to the cores at the hypervisor level, and intel's chips support independent (frequency) scaling of CPU cores for some time. In that scenario, mixed loads won't help. You'll have at least one pinned core, and it can scale relative to the VMs load (considering you also pin hypervisor cores, etc). So, it's possible to hit that pinned core and execute the same timing attack. I know it's a niche scenario, but it's not an impossible or implausible one. Another possibility is the servers which fill critical roles, but they're idle or in a constant low-load state to have headspace for high loads. Again, attacking these servers are plausible. Considering these servers are not open to internet most of the time, we're bordering on corporate espionage, but it's not the subject here.
- sterlind 4y ago
  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.
  - bayindirh 4y ago
    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?
  - robocat 4y ago
    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_enterprise_linux/6/html/performance_tuning_guide/s-cpu-irq https://access.redhat.com/documentation/en-us/red_hat_enterp...

bayindirh 4y ago

Sometimes response critical VMs are pinned to the cores at the hypervisor level, and intel's chips support independent (frequency) scaling of CPU cores for some time. In that scenario, mixed loads won't help. You'll have at least one pinned core, and it can scale relative to the VMs load (considering you also pin hypervisor cores, etc). So, it's possible to hit that pinned core and execute the same timing attack. I know it's a niche scenario, but it's not an impossible or implausible one. Another possibility is the servers which fill critical roles, but they're idle or in a constant low-load state to have headspace for high loads. Again, attacking these servers are plausible. Considering these servers are not open to internet most of the time, we're bordering on corporate espionage, but it's not the subject here.

sterlind 4y ago
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.
- bayindirh 4y ago
  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?
- robocat 4y ago
  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_enterprise_linux/6/html/performance_tuning_guide/s-cpu-irq https://access.redhat.com/documentation/en-us/red_hat_enterp...