I'm going to put this question out here for everyone who's had some experience building a JIT engine of some kind: what exactly is the danger of compiling code, even unknown code like from downloaded javascript, when the process' operating environment is supposed to be hardened anyways?
Is it just that the only way to do this is with VirtualAlloc()/mmap()? Could a 'safe' executable page allocator be created for just this purpose?
If the JIT'ing code is tricked into compiling and executing 'malicious' code, hasn't the operating environment - what libs the process can load, what syscalls it has access to, etc - already been security-hardened? My understanding of WinRT is that it's already a bit of a sand-boxed environment, with limited and measured access to the machine's resources.
If it's possible for the JIT'ed code to do something REALLY bad, like install a driver or write to arbitrary system files or something, then it was possible for the JIT'ing code to do that too, and that's almost certainly a really really bad thing.
Even if it's just a matter of the JIT'ed code violating the trust agreement between the user and the JIT'ing code (ie doing something that the user was OK with Firefox doing, like reading the address book, but doing it for malicious reasons), maybe a new trust agreement can be designed, that would make users aware that the JIT'ing program is inherently a bit more dangerous?
Or maybe what really needs to happen is we have to treat JIT's as pluggable, upgradable OS infrastructure, sort of like the image loader or dyld/ld-linux.so? In that case, if the Firefox would install a browser and the Firefox JIT'ter as separate components, and then Firefox would ask it's JIT'er to compile/execute javascript into a separate process - one with much more limited access to the machine?
First three rules of security: Layers, Layers, LAYERS.
To your point, in theory you could accomplish security by totally securing the JIT, or by totally securing the OS, and then exec's JITed code would be ok. However, totally secured JITers and OSs are as mythical as sufficiently smart compilers.
Totally secure, sure. Nothing nontrivial is totally secure, but...
One reasonable option would be requiring any JIT to be via a typed assembly language. You should be able to get a good compromise with close to the performance of native code and the security of verified bytecode from that.
Well, then you have to carefully vet every JITting assembly language. Microsoft in fact does this: the WinRT APIs run on .NET, which has an associated assembly language CIL (formerly MSIL) and JITting runtime, the CLR.
So, if you want a JIT via a typed assembly language you can compile down to CIL. Firefox could do this, but then they couldn't specialize their JIT to run JavaScript properly, which is the hard part anyways. V8 and Gecko are very cool engines, and compiling javascript to CIL wouldn't compete.
Is it just that the only way to do this is with VirtualAlloc()/mmap()? Could a 'safe' executable page allocator be created for just this purpose?
If the JIT'ing code is tricked into compiling and executing 'malicious' code, hasn't the operating environment - what libs the process can load, what syscalls it has access to, etc - already been security-hardened? My understanding of WinRT is that it's already a bit of a sand-boxed environment, with limited and measured access to the machine's resources.
If it's possible for the JIT'ed code to do something REALLY bad, like install a driver or write to arbitrary system files or something, then it was possible for the JIT'ing code to do that too, and that's almost certainly a really really bad thing.
Even if it's just a matter of the JIT'ed code violating the trust agreement between the user and the JIT'ing code (ie doing something that the user was OK with Firefox doing, like reading the address book, but doing it for malicious reasons), maybe a new trust agreement can be designed, that would make users aware that the JIT'ing program is inherently a bit more dangerous?
Or maybe what really needs to happen is we have to treat JIT's as pluggable, upgradable OS infrastructure, sort of like the image loader or dyld/ld-linux.so? In that case, if the Firefox would install a browser and the Firefox JIT'ter as separate components, and then Firefox would ask it's JIT'er to compile/execute javascript into a separate process - one with much more limited access to the machine?