When I say “program local” I mean code that doesn’t have to leave its own virtual address space, i.e. doesn’t call kernel code to do networking, filesystem, talk to drivers directly, free/allocate memory, etc. Really anything that has to talk to the kernel or pass through the kernel into protected memory space, which is what the bug is exploiting.
The performance losses are occurring because the hot fix workarounds being rolled out immediately focus on manually flushing certain CPU caches (from what I gather, branch prediction caches) in order to ensure malicious code with kernel-level access to memory isn’t running through the branch predictor.
Since this is a software workaround, it is essentially crippling the hardware in certain circumstances (i.e. entering a syscall) to compensate for the issue since hardware obviously can’t be updated with bug fixes like software can.
Those of us who do realtime programming on non-realtime systems (read: audio on typical PCs/mobile) don’t need to worry about the performance implications of this since we never do syscalls in the audio thread (or at least we’re really not supposed to) due to the indeterministic amount of time they will take - a notion reinforced by this surprise performance degradation.