> Pledge / unveil on userland
This sounds very nice, is there anything similar on Linux?
> SMT disabled
Well, this is one way to deal with spectre and friends.
This sounds very nice, is there anything similar on Linux?
> SMT disabled
Well, this is one way to deal with spectre and friends.
> This sounds very nice, is there anything similar on Linux?
Seccomp is the closest thing we have to pledge, and it is used by some programs to restrict the set of operations they can do (but the most common use of seccomp profiles is containers -- pretty much all container runtimes apply a default seccomp profile to reduce kernel attack surface reachable by containers).
As for unveil, you could implement it with mount namespaces (or an LSM like AppArmor -- which isn't actually that hard to set up, but unprivileged users may have to go through extra hoops) but most programs don't do that themselves.
But in short, not really. Most security mechanisms in Linux are intended to be managed by administrators or system services rather than the program itself (with some exceptions, but even those exceptions end up being managed by system services in practice).
If a program in a seccomp sandbox couldn't add a new secxokp filter to itself, you wouldn't be able to run programs like OpenSSH inside containers (which you can).
Aren't these caused by speculative execution? How does turning off hyperthreading help there?
That's right, if you don't have hyperthreading disabled right now, you are technically vulnerable. All the major players have decided that it's not worth the performance cost (or maybe just the feeling of loss of giving up that hyperthreading) for such a niche, difficult-to-exploit vulnerability.
A popular idea is to only allow threads of the same process to run on hyperthreads of the same core (or of processes in the same "security domain"). Patches to do this for linux have been floating around for about 2 years, they might have been merged recently, I'm not sure. But the performance cost of the logic that enforces this is greater than the performance benefit of hyperthreading in most cases.
IMHO either give up hyperthreading, or give up security against the "MDS" vulnerabilities. I leave it enabled for my gaming system, I think there are bigger problems if attackers have local execution on my system ;)
> IMHO either give up hyperthreading, or give up security against the "MDS" vulnerabilities. I leave it enabled for my gaming system, I think there are bigger problems if attackers have local execution on my system ;)
I made a similar tradeoff for my non-critical systems. But maybe that's a reason to not pay the extra for a HT CPU for my servers :)