Per-core EM leakage matters because once the cores stop looking like one blob, you can start separating neighboring workloads without pinning a probe to a specific signal path. People used to mostly treat multicore chips as if leakage from one core just drowned in the aggregate, so the usual playbook was coarse power analysis or a lot of calibration and hope.
The annoying part is that this pushes side-channel work from “can I recover a key from my own board” toward monitoring shared embedded boxes and SoCs in the field, where the attacker may only get an RF front-end and a nearby device. I’d still want the concrete setup parameters, though, since on this stuff the difference between “works in the lab” and “works at 50 dB SNR” is usually the whole paper.
> the difference between “works in the lab” and “works at 50 dB SNR” is usually the whole paper.
and the rpi 4b is a decent stress test, since the scheduler gets a vote too.
> and the rpi 4b is a decent stress test, since the scheduler gets a vote too.
Not really, the scheduler mostly changes noise and placement. If the leakage is per-core, the harder part is separation, not who got scheduled where.