With multiple processes you can apply more strict OS controls to one of the processes. That doesn't work with threads.

Which are ...?

See the problem is always local code execution. Once you have that, it's over. There are real mitigations (W^X, ASLR, stack cookies) and then there seems to be lore ("multi-process", "sandboxing").

Sandboxing absolutely does reduce attack surface, and that isn't just "lore". Nobody in the security field considers W^X superior to kernel-enforced sandboxing.

> Which are ...?

seccomp.

Local code execution doesn't mean a thing (except for wasted CPU cycles and/or memory) if number of syscalls the process can do is limited to the bare minimum.

And the Windows equivalent (win32k lockdown)[1]. This restricts a number of win32k syscalls including all GDI ones. Chrome already uses this mitigation for renderer processes and has support for PPAPI plugin processes on their dev/beta channels.

[1] https://msdn.microsoft.com/en-us/library/windows/desktop/hh8...

> There are real mitigations (W^X, ASLR, stack cookies)

We've had these for nearly a decade with other software. Have they completely stopped bugs/exploits in that time?

I'm not trying to take away from the usefulness of those mitigations against certain classes of exploits but the point of "lore" such as sandboxing is to promote defense in depth. If there's a buffer overflow which is exploitable then containing that in a restricted sandbox with no permissions to do anything requires more work to break out of.

> Which are ...?

I'm not an expert, but I wonder if this means you could restrict GPU access to the master process only (for the sake of hardware-accelerated compositing) without needing to expose it to the website-facing process (due to the security vulnerabilities in GPU drivers).

Angle (the OpenGL -> DirectX thingy) actually acts as a sanitizer for GPU commands so in a sense browsers which use Angle already have some protection over this. While I think complete protection is impossible through the use of Angle and GPU process I think you reduce it as much as you can since you can't control the driver itself aside from what protections Windows gives you by default.

That implies running Windows, though.

My biggest problem with GPU drivers is that they stick out like a sore thumb on a hardened system. All the protection and isolation in the world won't help you when you have a stock-compiled, PaX-disabled blob loaded into your binary that communicates directly with the kernel.

For this reason and this reason alone, I am forced to basically limit OpenGL access to X.org and mpv.

> That implies running Windows, though.

Indeed. My knowledge on Linux is pretty limited but I seem to remember that Nvidia fixed something which let you use Pax/grsecurity protections you otherwise couldn't. This still implies loading a binary blob but certain kernel protections could still help you IIRC (DEP?). I could be misremembering. I can't check since grsecurity set their twitter to protected.

I'm not sure what Chrome does aside from having a separate GPU process and whether or not any sanitizing takes place. They're pretty good with stuff like that so it would surprise me if some amount of protection wasn't offered.

Edit: There are some patches from the Pax folks for Nvidia drivers which I believe help with PAX_USERCOPY[1][2]? Although that may just be for getting it working...

[1] https://grsecurity.net/~paxguy1/

[2] https://grsecurity.net/~paxguy1/nvidia-drivers-367.35-pax.pa... (example)

Those patches are for running the nvidia kernel driver in a PaX-enabled kernel. It doesn't help you protect the actual libGL.so, which my concern was about.

(Indeed, I have to use those patches otherwise the nvidia kernel module wouldn't compile)

Did you not think of sandboxing?

Multi-process is not crash proof, it contains any code execution vulnerabilities to the process that hit the edge case in question.