Issue #21140 has been updated by tenderlovemaking (Aaron Patterson). maximecb (Maxime Chevalier-Boisvert) wrote in #note-8:
I'm skeptical of the idea of having third-party JITs as gems. This is exposing a ton of internal APIs that were not previously exposed, which could be potentially problematic if people start to rely on them. You have to think that random gems that are not actually JITs could begin to use these APIs.
These APIs are already exposed via RJIT in current releases. Since we've extracted RJIT as a gem, I don't think RJIT can work without access to these.
I can't stop you from making this change, but Ruby has a history of merging new features too fast without carefully considering the full implications. This is going to sound cynical, but Ruby is not your personal side-project, it's a piece of software that millions of people rely on.
I think it can be both a side project as well as a piece of software that millions of people rely on. That's been at the core of the culture of the global Ruby community since its inception. I think for many of us on the Ruby-core team, it is a side-project, and I don't think it's right to take that aspect away. What Kokubun and I are trying to achieve is to give people a way to experiment with the language in ways you may not be able to imagine right now.
If you want a playground to build a JIT and have fun, why not build your own implementation of Lox from Crafting Interpreters or fork an existing one? I'm sorry if this sounds harsh, but I think we all need to ponder merging big changes really carefully. You too should at least try to play the devil's advocate here. What are the downsides?
My two biggest concerns: 1. The additional maintenance burden of random gems relying on internal APIs they shouldn't rely on. Think of the JIT challenges we run into with people abusing binding now. The Ruby public API surface is already too big imo.
I think it's important we document that this API is unstable / unreliable. That is why I called it `RubyVM::Internals` to try to indicate how private it is. Additionally it's an API that just returns an integer, so using this API is particularly hard.
2. What does this mean for security? If you have access to these APIs from Rubyland you can potentially take control of the Ruby VM. Is access to these internal APIs restricted somehow?
I don't think this change has any impact with regard to security. This information can be recovered via `dlsym` or parsing ELF / DWARF. This change just makes access somewhat easier. ---------------------------------------- Feature #21140: Add a method to get the address of certain JIT related functions https://bugs.ruby-lang.org/issues/21140#change-112025 * Author: tenderlovemaking (Aaron Patterson) * Status: Open ---------------------------------------- Feature #21116 extracted RJIT as a gem. But RJIT accesses certain internal functions which it cannot access as a gem. For example it used the `rb_str_bytesize` function, but this symbol is not exported, so we cannot access it (even from a C extension). Instead of exporting these symbols, I would like to propose an API for getting access to their addresses in Ruby. For example ```ruby RubyVM::RJIT.address_of(:rb_str_bytesize) # => 123456 ``` I would like to limit the addresses to [this list](https://github.com/ruby/ruby/blob/f32d5071b7b01f258eb45cf533496d82d5c0f6a1/t...) which are the ones required by RJIT. -- https://bugs.ruby-lang.org/