4 ms·

This seems like something that WebAssembly (misnomer) is set to resolve, to some degree. Sandboxing capabilities is easy because all of the wasm module imports

by cnity 5y ago

This seems like something that WebAssembly (misnomer) is set to resolve, to some degree. Sandboxing capabilities is easy because all of the wasm module imports must be provided by the process that initializes the module, so you can view imports as a kind of list of "requests for capabilities".

devwastaken 5y ago
Wasm addresses memory and execution isolation from the rest of the system, however anything running in it maintains it's exploitable logic internally. If the application needs to read/write files, and someone exploits that logic, wasm won't help. The only thing that could is limiting the filesystem access in the first place and building secure software to begin with.
dijit 5y ago
I think that's leaning even more into the parents point. We make a sandbox (in this case a very inefficient one) -- we assume the sandbox is the only way to deploy software, but mostly it's not because there will be times you need more than the sandbox or the software doesn't work, and then you're running "privileged" WASM routines. The sandbox itself might even require some kind of leaky behaviour, such as accessing files or shared memory. The wheel keeps turning. Some new sandbox will come along.
- Hnus 5y ago
  WASM will probably be always slower than native but call it very inefficient is unjustified imho considering the compiler needs to be fast enough to run in browser from what I have seen its around ~1.5x slower than native code with there still being many low hanging fruits to be optimized.
  - dijit 5y ago
    prefer not to get into a debate about the efficiencies of x vs y but sufficed to say: Computers are only getting negligibly faster over the last 10 years and our software has gotten overall quite considerably slower. A runtime overhead that slows everything down to 1.5x, even with low hanging fruits is only going to accelerate this issue. From a consumer perspective: We all act as if everyone has 8-16G of ram, because that's what we're used to, but the reality is that the majority of people have 2-4G of ram, even these days. That's not counting the anemic CPUs that are often inside awful cooling solutions. From a server perspective: we outsource our Ops to cloud providers and pay a significant premium for computational speed, which means things like runtime overheads have direct costs. The reason I called it inefficient is because it's not adding anything we don't have, it's just "another layer" with a large runtime overhead. And, anyway, I'm mainly referring to this talk: https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...
    - hajile 5y ago
      That talk makes the point that replacing the swiss cheese hardware security models with a software one can shift your performance. You run 1.5x slower, but you also run 1.5x faster by avoiding all the hardware checks. On the whole, you can theoretically run about the same speed, but with better security. Even better, if WASM takes over the world, you can bake parts of it into hardware and remove a lot of other bottlenecks.
  - kllrnohj 5y ago
    1.5x slower for a weak sandbox that's already hardware compromised (spectre) with no plans to ever be fixed, along with a questionable portability story (cool the instructions itself are portable, but there's no APIs. Which are, and always have been, the actual portability issue) does not exactly sound compelling. It makes sense on the web where the browser is already providing API portability & permission sandboxing, and all that's necessary is actually just instruction portability and protection against eg memory corruption (actual security sandboxing still being done via process isolation), but beyond that? Like desktop apps? Pretty much entirely useless. And it doesn't address any of the issues here anyway. As soon as you bind libc to it (or any other system library), which isn't exactly unlikely, you're right back into the problem of not knowing what the selinux policy should be. And you still want selinux policies since WASM is only a memory sandbox, not a permission sandbox.
- cassianoleal 5y ago
  > and then you're running "privileged" WASM routines That's pretty much where snap ended at, isn't it?
kaba0 5y ago
Why would a completely new compilation target be needed for that when “old” sandboxes can work just fine by hijacking syscalls? Sure, memory safety is somewhat improved by Wasm, but valgrind and the like are effectively giving you the same thing.

by cnity 5y ago

devwastaken 5y ago

Wasm addresses memory and execution isolation from the rest of the system, however anything running in it maintains it's exploitable logic internally. If the application needs to read/write files, and someone exploits that logic, wasm won't help. The only thing that could is limiting the filesystem access in the first place and building secure software to begin with.

dijit 5y ago

I think that's leaning even more into the parents point. We make a sandbox (in this case a very inefficient one) -- we assume the sandbox is the only way to deploy software, but mostly it's not because there will be times you need more than the sandbox or the software doesn't work, and then you're running "privileged" WASM routines. The sandbox itself might even require some kind of leaky behaviour, such as accessing files or shared memory. The wheel keeps turning. Some new sandbox will come along.

Hnus 5y ago
WASM will probably be always slower than native but call it very inefficient is unjustified imho considering the compiler needs to be fast enough to run in browser from what I have seen its around ~1.5x slower than native code with there still being many low hanging fruits to be optimized.
- dijit 5y ago
  prefer not to get into a debate about the efficiencies of x vs y but sufficed to say: Computers are only getting negligibly faster over the last 10 years and our software has gotten overall quite considerably slower. A runtime overhead that slows everything down to 1.5x, even with low hanging fruits is only going to accelerate this issue. From a consumer perspective: We all act as if everyone has 8-16G of ram, because that's what we're used to, but the reality is that the majority of people have 2-4G of ram, even these days. That's not counting the anemic CPUs that are often inside awful cooling solutions. From a server perspective: we outsource our Ops to cloud providers and pay a significant premium for computational speed, which means things like runtime overheads have direct costs. The reason I called it inefficient is because it's not adding anything we don't have, it's just "another layer" with a large runtime overhead. And, anyway, I'm mainly referring to this talk: https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...
  - hajile 5y ago
    That talk makes the point that replacing the swiss cheese hardware security models with a software one can shift your performance. You run 1.5x slower, but you also run 1.5x faster by avoiding all the hardware checks. On the whole, you can theoretically run about the same speed, but with better security. Even better, if WASM takes over the world, you can bake parts of it into hardware and remove a lot of other bottlenecks.
- kllrnohj 5y ago
  1.5x slower for a weak sandbox that's already hardware compromised (spectre) with no plans to ever be fixed, along with a questionable portability story (cool the instructions itself are portable, but there's no APIs. Which are, and always have been, the actual portability issue) does not exactly sound compelling. It makes sense on the web where the browser is already providing API portability & permission sandboxing, and all that's necessary is actually just instruction portability and protection against eg memory corruption (actual security sandboxing still being done via process isolation), but beyond that? Like desktop apps? Pretty much entirely useless. And it doesn't address any of the issues here anyway. As soon as you bind libc to it (or any other system library), which isn't exactly unlikely, you're right back into the problem of not knowing what the selinux policy should be. And you still want selinux policies since WASM is only a memory sandbox, not a permission sandbox.
cassianoleal 5y ago
> and then you're running "privileged" WASM routines That's pretty much where snap ended at, isn't it?

kaba0 5y ago

Why would a completely new compilation target be needed for that when “old” sandboxes can work just fine by hijacking syscalls? Sure, memory safety is somewhat improved by Wasm, but valgrind and the like are effectively giving you the same thing.