moonchild wrote:There are formally verified JITs. I linked one already;
here's another more mature one.
Verifying the code is important, but that's not the issue. JIT compilation requires that userspace code must be able to write memory which later will be executed as code. This opens up the possibility to inject code with buffer overflow attacks (unrelated to JIT), essentially putting you back in the era before NX bit got widespread. On ARM for example, you can globally configure the MMU to only allow executing a memory which is not writable (called W^X, referring to "exclusive or"). In order to implement JIT, you must turn this security feature globally off.
With interpreters, you can make sure of it that all code is read-only and all data is non-executable for ring 3 tasks, making it impossible inject code with buffer overflow (unless the buffer overflow is in ring 0 which still can write code into memory). A possible solution could be a JIT compiler running in ring 0 and then executing the generated code in ring 3, but I haven't seen such a solution (yet).
AndrewAPrice wrote:how would you implement this private property without an instance of FileSystem passed in?
You misunderstood, the whole point is, there should be no need to pass the FileSystem instance during calls. One time in the code, during initialization, you create an instance and save that in a static private property. Then later, in the static method calls, they can get that instance without the caller knowing anything about it.
Code: Select all
// okay, stupid example, but I hope you get what I mean
FileSystem::init()
{
FileSystem::vfs = new VFS();
// ... other things to do during init
}
// just an example method for accessing it
FileSystem::ReadFile(fn)
{
if (FileSystem::vfs == NULL) return ERROR;
FILE *f = FileSystem::vfs->Open(fn);
buffer buf = FileSystem::vfs->Read(f);
FileSystem::vfs->Close(f);
return buf;
}
Not a valid code, just to demonstrate private property usage. NOTE: instance stored in a property, so it's not global, yet GC should not release it while FileSystem class is accessable. When you unload the FileSystem code from memory, then it will be freed along with the other FileSystem properties.
In my example OOP code that I linked, the
property is set in the main class' constructor like "self::$core = &$this;" (I instantiate PHPPE\Core class only
once). Then the static methods can access this instance anytime if they need it (for example in
PHPPE\Core::lib()).
I'd like to point out that this trick only works for 'root' objects, which are singletons (such as the VFS). For classes with multiple objects (like mount points of the same file system type), you should use separate instances as usual (and maybe store them in an array in a VFS property). Also there's a need for language support to allow instantiating static classes and making static method calls of that same class. Have no mistake, this is a dirty hack so that caller don't have to pass instance references around
Cheers,
bzt
