4 ms·

How would you enforce bounds checking while supporting unsafe languages?

pjmlp 7y ago
That is exactly the point, don't advertise WebAssembly as safe bytecode, if unsafe languages are part of the picture without any kind of control. Secondly, nor ISO C or ISO C++ forbid implementations that do bounds checking by default. In fact that is what most modern compilers do by default in debug mode. Finally look at memory tagging in Solaris SPARC ADI, Apple iOS or the upcoming ARM extensions support on Android for how bounds checking is enforced at hardware level while supporting unsafe languages.
- saagarjha 7y ago
  > In fact that is what most modern compilers do by default in debug mode. Assuming that “debug mode” is -g or equivalent, then I have not seen a modern compiler that does this.
  - swiley 7y ago
    He’s probably talking about instrumentation (valgrind, ASAN etc.) That’s part of why running instrumented code feels like running python.
    - pjmlp 7y ago
      No, just plain bounds checking on C++ standard library and integration with hardware memory tagging when available.
  - pjmlp 7y ago
    Then get to use Visual C++, which does bounds checking on collection types (array, string, vector,...), memory dumps leaks at exit. Or Solaris SPARC and iOS compilers that make use of hardware memory tagging. Clang and GCC do need extra flags to enable FORTIFY mode though. However on Android FORTIFY is now a requirement and future versions will make use of memory tagging on ARM hardware. So ironically something like Android does have a better sandboxing model as WebAssembly.
    - saagarjha 7y ago
      > iOS compilers that make use of hardware memory tagging No iOS devices ship with ARMv8.5, so while I think compilers are implementing this today I am not sure if Xcode ships with this or if it's functional. > So ironically something like Android does have a better sandboxing model as WebAssembly. …you're not understanding what sandboxing means.
      - pjmlp 7y ago
        Apple has their own CPUs, https://developer.apple.com/documentation/security/preparing_your_app_to_work_with_pointer_authentication https://developer.apple.com/documentation/security/preparing... I do understand what sandboxing means, and how WebAssembly advocates keep overselling its security capabilities, by ignoring issues that other bytecode formats have taken a more serious approach, already in the mid-60's.
        saagarjha 7y ago
        Pointer authentication≠memory tagging. The former requires ARMv8.3 and is in the A12 processor, and the latter is not in any hardware that Apple is currently shipping.
        pjmlp 7y ago
        Yep, fighting windmills here.
        afiori 7y ago
        I believe that wasm is not particularly focused on functional security as much as embeddable security. Essentially the promise here is that you can download a random wasm from anywhere, run it with little-to-none privileges and be sure nothing bad can happen. There was an article here many months ago detailing how wasm on the server makes it harder to mitigate attacks due to lack of wasm-inspecting tooling compared to system utilities for processes/native binaries. But in part that is because the attack model of wasm is "literally executing malicious code".
- connicpu 7y ago
  The point of the byte code being safe is that no operations performed by WASM code could cause a memory unsafety bug from the perspective outside the sandbox. If your code violates its own memory rules then it will only mess up the logical state of its VM memory chunk, and probably produce an incorrect result. The same thing can happen in any safe language if you access the wrong indexes in an array because of a logical error in your code
  - pjmlp 7y ago
    That incorrect results might lead to security exploits, the same way that browsers now get exploited by taking advantage how their VMs work. So hand waving such security issues is rather strange, when it should be the top concern when selling an infrastructure to run code from unknown sources.
    - afiori 7y ago
      > the same way that browsers now get exploited by taking advantage how their VMs work The difference is if the exploit is run by the browser or the VM. If the VM has a logic error, gives back the wrong result, the browser decides to trust the result and be exploited then it is a browser bug; not a sandbox issue. The other situation is when a browser spins up a VM to add 2 and 2 but then the VM starts downloading malicious files from the internet. No kind of safe language can avoid the first class, wasm avoids the second.

That is exactly the point, don't advertise WebAssembly as safe bytecode, if unsafe languages are part of the picture without any kind of control. Secondly, nor ISO C or ISO C++ forbid implementations that do bounds checking by default. In fact that is what most modern compilers do by default in debug mode. Finally look at memory tagging in Solaris SPARC ADI, Apple iOS or the upcoming ARM extensions support on Android for how bounds checking is enforced at hardware level while supporting unsafe languages.

saagarjha 7y ago
> In fact that is what most modern compilers do by default in debug mode. Assuming that “debug mode” is -g or equivalent, then I have not seen a modern compiler that does this.
- swiley 7y ago
  He’s probably talking about instrumentation (valgrind, ASAN etc.) That’s part of why running instrumented code feels like running python.
  - pjmlp 7y ago
    No, just plain bounds checking on C++ standard library and integration with hardware memory tagging when available.
- pjmlp 7y ago
  Then get to use Visual C++, which does bounds checking on collection types (array, string, vector,...), memory dumps leaks at exit. Or Solaris SPARC and iOS compilers that make use of hardware memory tagging. Clang and GCC do need extra flags to enable FORTIFY mode though. However on Android FORTIFY is now a requirement and future versions will make use of memory tagging on ARM hardware. So ironically something like Android does have a better sandboxing model as WebAssembly.
  - saagarjha 7y ago
    > iOS compilers that make use of hardware memory tagging No iOS devices ship with ARMv8.5, so while I think compilers are implementing this today I am not sure if Xcode ships with this or if it's functional. > So ironically something like Android does have a better sandboxing model as WebAssembly. …you're not understanding what sandboxing means.
    - pjmlp 7y ago
      Apple has their own CPUs, https://developer.apple.com/documentation/security/preparing_your_app_to_work_with_pointer_authentication https://developer.apple.com/documentation/security/preparing... I do understand what sandboxing means, and how WebAssembly advocates keep overselling its security capabilities, by ignoring issues that other bytecode formats have taken a more serious approach, already in the mid-60's.
      - saagarjha 7y ago
        Pointer authentication≠memory tagging. The former requires ARMv8.3 and is in the A12 processor, and the latter is not in any hardware that Apple is currently shipping.
        pjmlp 7y ago
        Yep, fighting windmills here.
      - afiori 7y ago
        I believe that wasm is not particularly focused on functional security as much as embeddable security. Essentially the promise here is that you can download a random wasm from anywhere, run it with little-to-none privileges and be sure nothing bad can happen. There was an article here many months ago detailing how wasm on the server makes it harder to mitigate attacks due to lack of wasm-inspecting tooling compared to system utilities for processes/native binaries. But in part that is because the attack model of wasm is "literally executing malicious code".
connicpu 7y ago
The point of the byte code being safe is that no operations performed by WASM code could cause a memory unsafety bug from the perspective outside the sandbox. If your code violates its own memory rules then it will only mess up the logical state of its VM memory chunk, and probably produce an incorrect result. The same thing can happen in any safe language if you access the wrong indexes in an array because of a logical error in your code
- pjmlp 7y ago
  That incorrect results might lead to security exploits, the same way that browsers now get exploited by taking advantage how their VMs work. So hand waving such security issues is rather strange, when it should be the top concern when selling an infrastructure to run code from unknown sources.
  - afiori 7y ago
    > the same way that browsers now get exploited by taking advantage how their VMs work The difference is if the exploit is run by the browser or the VM. If the VM has a logic error, gives back the wrong result, the browser decides to trust the result and be exploited then it is a browser bug; not a sandbox issue. The other situation is when a browser spins up a VM to add 2 and 2 but then the VM starts downloading malicious files from the internet. No kind of safe language can avoid the first class, wasm avoids the second.