IMHO it's stupid to even try to isolate processes to that extent, as it's a really deep rabbithole that'll lead to worse performance and dubious increases in actual security. The best defense is to simply make everything running on the system be trusted.
Process protection boundaries should be for protection against accidental cross-process corruption, a form of reliability, and nothing more. That's effectively what the early 286/386 documentation stated, so Intel never even intended these protections to be defenses against side-channels in the first place.
Of course, the "security industry" needs to keep creating paranoia-fuel to justify their existence...
> Of course not.
So if it's not OK for processes to read each others' address spaces, does that mean it's not OK to attach gdb to a running process to figure out where it's stuck at, without running gdb as root? I chose to reenable ptrace among sibling processes on my system out of convenience, and hopefully it's not too much of a vulnerability. (I also chose to enable passwordless sudo, which is convenient, but probably dangerous as well. I wonder if I can use my hardware security key for sudo instead.)
I guess if "basically" means "takes 10x longer"?
(I don't know if dial-up is still 56 kb/s these days, but that's the speed historically associated with the term.)
I would assume other IPC mechanisms are safe from it.
IPC really has nothing to do with anything, Spectre-wise; you don’t have to be using any IPC mechanism in either the attacker or attackee process to be vulnerable to these variants.
Side-channels are pernicious. In the limit, they give applications unfettered read access across protection boundaries. If we don't shut them down, we might as well throw out the whole UNIX process boundary security model.
Ask yourself, would it be fine if every process had a 4KB/s (basically dialup speed) connection to read any desired byte of another process's address space?
Of course not. Thus, we need mitigations to shut these channels down.