4 ms·

If you're generating machine code at runtime (JIT), you can have memory bugs no matter what language your JIT is written in.

Voultapher 3y ago
Well maybe such a JIT is an inappropriate choice for a sandbox. There are under-explored safe alternatives such as isomorphic interpreters e.g. https://blog.cloudflare.com/building-fast-interpreters-in-rust https://blog.cloudflare.com/building-fast-interpreters-in-ru... personally I've written one such implementation that could hold it's own compared to a LLVM based JIT.
- infamouscow 3y ago
  There's a lot of hobbyists that can compete with LLVM's JIT, and they do it without any formal training in PLT or compilers.
- olliej 3y ago
  The whole point is the implementation and runtime for any safe language _requires_ code that is fundamentally unsafe. If you write a safe interpreter your safety is still dependent on the compiler and runtime for your safe language having no errors. This specific bug is in the implementation of a safe language, and the same can happen in any other (safe) language. People file bug reports on rustc, clang, llvm, etc all the time, and the only difference is that targeting them as an attack vector is not not particularly valuable as it's much harder to get a target to run your attack code, and the methods for doing so are much harder to hide. Note that these errors do not have to be any kind of safety error in the compiler for those languages, they can easily be erroneous codegen. These things happen. As another example, I've seen use after free bugs in WebKit and JSC come up on HN over the years, and people blame C++ memory management, when the use after failure is incorrect management of the JS GC state in the GC runtime. If you have a GCd language, then code written in that language is definitionally incapable of making memory management errors, but if you are implementing the runtime that provides that safety you are inherently and unavoidably doing things that are "unsafe" under the definition of the hosted language. The decision of many people is that JS needs to be fast, but if you disagree you can always see what the perf delta is. IIRC for non-hot code the JSC baseline JIT is maybe 10x faster than the interpreter (which is written in a pseudo assembly, so it's not taking any C/C++ overhead), and if the code is hot enough that it starts getting optimized that number just gets larger. I'm not sure what language you were compiling where your interpreter was holding its own to LLVM, but the options that would make that plausible all imply the dominant component of the runtime was not the code being interpreted. e.g. along the same lines of people comparing python performance by benchmarking C and fortran math libraries.
  - Voultapher 3y ago
    Equating the provided memory safety of a Rust program without direct unsafe usage to a complex JIT built in C++ seems willfully ignorant. The attack surface would still be the mostly formally verified Rust type system and standard library https://plv.mpi-sws.org/rustbelt/ https://plv.mpi-sws.org/rustbelt/.
    - kldx 3y ago
      For the JS lifetime machinery that's entirely out of rust's borrow checker shouldn't one verify the properties of unsafe code (which I imagine the garbage collector would use)? As I understand it, Rusthornbelt exists to prove unsafe code at the cost of manual verification. As someone who's a novice in verification using model checkers, writing proofs for simple algorithms is hard enough already, so I don't see the viability of a fully verified JIT. Is there a CompCert-C equivalent for V8/JSC?
      - Voultapher 3y ago
        The isomorphic interpreter that I was talking about, and as shown in the cloudflare blog, does not generate new machine code. All it does is jump around in the statically verified safe Rust code. So it is extremely robust. Even if there are logic bugs in it, they will not manifest as UB.
technion 3y ago
Interestingly Edge gives you the option to disable the JIT wholesale. https://support.microsoft.com/en-us/microsoft-edge/enhance-your-security-on-the-web-with-microsoft-edge-b8199f13-b21b-4a08-a806-daed31a1929d https://support.microsoft.com/en-us/microsoft-edge/enhance-y... I've had this in place on some workstations and I've never actually noticed a performance difference.
- throwitaway1123 3y ago
  You can do this in Safari too, it's a system setting called Lockdown Mode. In desktop Chrome it's a command line flag, and in Firefox it's in the settings page: https://web.archive.org/web/20230628134258/https://lemmy.eus/post/7660 https://web.archive.org/web/20230628134258/https://lemmy.eus...

Voultapher 3y ago

Well maybe such a JIT is an inappropriate choice for a sandbox. There are under-explored safe alternatives such as isomorphic interpreters e.g. https://blog.cloudflare.com/building-fast-interpreters-in-rust https://blog.cloudflare.com/building-fast-interpreters-in-ru... personally I've written one such implementation that could hold it's own compared to a LLVM based JIT.

infamouscow 3y ago
There's a lot of hobbyists that can compete with LLVM's JIT, and they do it without any formal training in PLT or compilers.
olliej 3y ago
The whole point is the implementation and runtime for any safe language _requires_ code that is fundamentally unsafe. If you write a safe interpreter your safety is still dependent on the compiler and runtime for your safe language having no errors. This specific bug is in the implementation of a safe language, and the same can happen in any other (safe) language. People file bug reports on rustc, clang, llvm, etc all the time, and the only difference is that targeting them as an attack vector is not not particularly valuable as it's much harder to get a target to run your attack code, and the methods for doing so are much harder to hide. Note that these errors do not have to be any kind of safety error in the compiler for those languages, they can easily be erroneous codegen. These things happen. As another example, I've seen use after free bugs in WebKit and JSC come up on HN over the years, and people blame C++ memory management, when the use after failure is incorrect management of the JS GC state in the GC runtime. If you have a GCd language, then code written in that language is definitionally incapable of making memory management errors, but if you are implementing the runtime that provides that safety you are inherently and unavoidably doing things that are "unsafe" under the definition of the hosted language. The decision of many people is that JS needs to be fast, but if you disagree you can always see what the perf delta is. IIRC for non-hot code the JSC baseline JIT is maybe 10x faster than the interpreter (which is written in a pseudo assembly, so it's not taking any C/C++ overhead), and if the code is hot enough that it starts getting optimized that number just gets larger. I'm not sure what language you were compiling where your interpreter was holding its own to LLVM, but the options that would make that plausible all imply the dominant component of the runtime was not the code being interpreted. e.g. along the same lines of people comparing python performance by benchmarking C and fortran math libraries.
- Voultapher 3y ago
  Equating the provided memory safety of a Rust program without direct unsafe usage to a complex JIT built in C++ seems willfully ignorant. The attack surface would still be the mostly formally verified Rust type system and standard library https://plv.mpi-sws.org/rustbelt/ https://plv.mpi-sws.org/rustbelt/.
  - kldx 3y ago
    For the JS lifetime machinery that's entirely out of rust's borrow checker shouldn't one verify the properties of unsafe code (which I imagine the garbage collector would use)? As I understand it, Rusthornbelt exists to prove unsafe code at the cost of manual verification. As someone who's a novice in verification using model checkers, writing proofs for simple algorithms is hard enough already, so I don't see the viability of a fully verified JIT. Is there a CompCert-C equivalent for V8/JSC?
    - Voultapher 3y ago
      The isomorphic interpreter that I was talking about, and as shown in the cloudflare blog, does not generate new machine code. All it does is jump around in the statically verified safe Rust code. So it is extremely robust. Even if there are logic bugs in it, they will not manifest as UB.

technion 3y ago

Interestingly Edge gives you the option to disable the JIT wholesale. https://support.microsoft.com/en-us/microsoft-edge/enhance-your-security-on-the-web-with-microsoft-edge-b8199f13-b21b-4a08-a806-daed31a1929d https://support.microsoft.com/en-us/microsoft-edge/enhance-y... I've had this in place on some workstations and I've never actually noticed a performance difference.

throwitaway1123 3y ago
You can do this in Safari too, it's a system setting called Lockdown Mode. In desktop Chrome it's a command line flag, and in Firefox it's in the settings page: https://web.archive.org/web/20230628134258/https://lemmy.eus/post/7660 https://web.archive.org/web/20230628134258/https://lemmy.eus...