4 ms·

That could be and that analysis really is quite long. I’ll have to take your word on that as I don’t have the experience you do. I do know that most JITs don’t

That could be and that analysis really is quite long. I’ll have to take your word on that as I don’t have the experience you do. I do know that most JITs don’t have to even worry about this as they don’t need to worry about running untrusted code (not sure about the real world deployments for GraalJS). It’s also true that v8 has a lot more usage and vulnerabilities in it like this are a lot more valuable. So it can be hard to compare and contrast how different approaches impact vulnerabilities (+ comparing vulnerabilities is really difficult). But generally it is true that higher level abstractions can reduce certain classes of defects (not sure if this one falls into that but certainly others). All that being said, the changes you suggest sound more like a design choice than something specific to a language. V8 has a complex build process and an object graph that should let you get the necessary compile time and runtime reflection capabilities. Anyway, I think we can both agree that compiler research generally assumes trusted inputs but there’s not much research in building robust compilers and JITs that are secure against malicious input. We know generic techniques like fuzzing but no really robust designs (in terms of the level of protection we know related to memory safety)

mike_hearn 3y ago
Graal/Truffle languages can support sandboxing and GraalJS does. So it's designed to run untrusted code. I think in this specific case it's really hard to say. It's sort of on the borderline. But we can imagine many other closely related cases where the higher level abstraction would help. You could potentially do something like Truffle with C++ and LLVM, but I don't think it'd be easy. The grain of the language works against you. It's interesting if V8 already has added some of the infrastructure necessary.
- vlovich123 3y ago
  You'd be surprised how much friction you'd have for C++ reflection. First, since it's a custom build step, you can do a mix of custom code gen and C++ constexpr/consteval for static reflection. Here's a header-only implementation for adding compile time reflection purely within the language [1]. And v8 already does dynamic code gen as part of its build process (to generate the snapshot to speedup instantiation of the isolate). Some amount of dynamic reflection is also a must since JS is a dynamic language with reflection support + you need to walk the GC tree. Of course none of this necessarily exists within the compiler part of the codebase as it's unlikely to be needed there, but clearly doable. I don't know the specific details of reflection needed for the abstractions you reference and clearly V8 is still doing some amount of manual IR generation, so it's possible it would be a substantial investment to actually retrofit those techniques into v8 (+ the current capabilities may exist in the wrong part of the codebase for applying it to the JIT itself). One would have to do a careful analysis of historical security exploits & specific techniques and their ability to prevent to figure out if it's worth adding those abstractions (especially since there is a potential performance tradeoff as you mention). As I said, I think there's insufficient research in this area to establish a compelling body of best practices (not to take away from the contributions of the GraalJS team to this space). [1] https://github.com/veselink1/refl-cpp https://github.com/veselink1/refl-cpp

mike_hearn 3y ago

Graal/Truffle languages can support sandboxing and GraalJS does. So it's designed to run untrusted code. I think in this specific case it's really hard to say. It's sort of on the borderline. But we can imagine many other closely related cases where the higher level abstraction would help. You could potentially do something like Truffle with C++ and LLVM, but I don't think it'd be easy. The grain of the language works against you. It's interesting if V8 already has added some of the infrastructure necessary.

vlovich123 3y ago
You'd be surprised how much friction you'd have for C++ reflection. First, since it's a custom build step, you can do a mix of custom code gen and C++ constexpr/consteval for static reflection. Here's a header-only implementation for adding compile time reflection purely within the language [1]. And v8 already does dynamic code gen as part of its build process (to generate the snapshot to speedup instantiation of the isolate). Some amount of dynamic reflection is also a must since JS is a dynamic language with reflection support + you need to walk the GC tree. Of course none of this necessarily exists within the compiler part of the codebase as it's unlikely to be needed there, but clearly doable. I don't know the specific details of reflection needed for the abstractions you reference and clearly V8 is still doing some amount of manual IR generation, so it's possible it would be a substantial investment to actually retrofit those techniques into v8 (+ the current capabilities may exist in the wrong part of the codebase for applying it to the JIT itself). One would have to do a careful analysis of historical security exploits & specific techniques and their ability to prevent to figure out if it's worth adding those abstractions (especially since there is a potential performance tradeoff as you mention). As I said, I think there's insufficient research in this area to establish a compelling body of best practices (not to take away from the contributions of the GraalJS team to this space). [1] https://github.com/veselink1/refl-cpp https://github.com/veselink1/refl-cpp