4 ms·

> 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 friend

by stjo 6y ago

> 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.

lmohseni 6y ago
Also, it's not mentioned in TFA, but by default the kernel does not allow audio recording :).
da_big_ghey 6y ago
Indeed, the OpenBSD guys said early on that hyperthreading should just be disabled for security reasons. It took everyone else to catch up, but see Greg KH's comments that if users are untrusted, one should do so: https://www.youtube.com/watch?v=jI3YE3Jlgw8 https://www.youtube.com/watch?v=jI3YE3Jlgw8
cyphar 6y ago
> > Pledge / unveil on userland > 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).
- gbrown_ 6y ago
  Just to add, pledge can be called repeatedly throughout the program to reduce the behaviors that are permitted unlike seccomp.
  - cyphar 6y ago
    You can do that with seccomp -- each filter is run along with the others and the most restrictive return value is used by seccomp. 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).
Sebb767 6y ago
> Well, this is one way to deal with spectre and friends. Aren't these caused by speculative execution? How does turning off hyperthreading help there?
- ploxiln 6y ago
  The kernel can pull "tricks" to mitigate speculative execution during context switches. But it can't do anything to prevent a process running on one hyperthread from using side-channel attacks against another process, or the kernel, or a secure enclave, running on the other hyperthread of the same core. 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 ;)
  - Sebb767 6y ago
    Thanks for the explanation! > 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 :)

by stjo 6y ago

> 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.

lmohseni 6y ago

Also, it's not mentioned in TFA, but by default the kernel does not allow audio recording :).

da_big_ghey 6y ago

Indeed, the OpenBSD guys said early on that hyperthreading should just be disabled for security reasons. It took everyone else to catch up, but see Greg KH's comments that if users are untrusted, one should do so: https://www.youtube.com/watch?v=jI3YE3Jlgw8 https://www.youtube.com/watch?v=jI3YE3Jlgw8

cyphar 6y ago

> > Pledge / unveil on userland > 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).

gbrown_ 6y ago
Just to add, pledge can be called repeatedly throughout the program to reduce the behaviors that are permitted unlike seccomp.
- cyphar 6y ago
  You can do that with seccomp -- each filter is run along with the others and the most restrictive return value is used by seccomp. 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).

Sebb767 6y ago

> Well, this is one way to deal with spectre and friends. Aren't these caused by speculative execution? How does turning off hyperthreading help there?

ploxiln 6y ago
The kernel can pull "tricks" to mitigate speculative execution during context switches. But it can't do anything to prevent a process running on one hyperthread from using side-channel attacks against another process, or the kernel, or a secure enclave, running on the other hyperthread of the same core. 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 ;)
- Sebb767 6y ago
  Thanks for the explanation! > 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 :)