A verifier would catch the cases you proposed here.

I don’t really know the details. Apparently there is no thisContext in VisualSmalltalk, but you can somehow access the contexts stack using Process, although it’s not the same.

However, they do have something like what you describe to cope with BlockClosures:

The prologue of a nativized method somehow depends on the Blocks in the method, and there are some cases where the prologue includes an Array creation, and in this cases, locals and temps are accessed with a different set of Bytecodes: LoadContextTemporary/PushContextTemporary/StoreContextTemporary

This newly created Array referencing to context slots is somehow called “environment temporaries”. You can see the logic of how it’s used (at compile time) in ScriptNode >> #rebindTemporaries, at some point it reads:

info := tempScope bindingFor: t value ifNone: [].
info isExternallyReferenced
ifTrue: [
t
binding: (self environmentTemporaryBindingClass new
name: t value
position: self incEnvTemporaryCount).
t binding markReferenced]
ifFalse: [
t
binding: (self stackTemporaryBindingClass new
name: t value
position: self incStackTemporaryCount)].

(how do you do nicely formatted posts on this blog?)

Most of this is guess work, as you can imagine.

On the security issues:

Using NoFramePrologue was just an example. I’ll give you another example now, but the key point is: Security problems can be all over the place, from design down to implementation. Security in VMs is usually dealt with through sandboxing of some sort, but when it comes to a JIT, there are more problems: basically, if an attacker can control VM Bytecodes, he can somehow control what native code is emitted, and, unless specific validation is made, it’s quite possible the attacker can escape the VM.

So, another example, from VisualSmalltalk, would be:

(Object >> #methodDictionaryArray:) byteCodeArray: #[16r50 16r9D 0 16r48]

Bytecodes:

16r50 LoadArgument1
16r9D StoreInstanceN 0
16r48 Return

You can use this method to change the methodDictionaryArray of any object. It works because instance variables are indexes as 1-based, hence StoreInstanceN 0, stores at instance variable 0, which is just before the first instance variable, i.e. the methodDictionaryArray of the Object.

In VisualSmalltalk there’s already a primitive (97) to do this (which could be protected through some sort of Sandboxing). However, this not only breaks the integrity of objects, it’s even worst (tested):

16r12345678 methodDictionaryArray: ‘hola amigos!’

will write a pointer to the string ‘hola amigos’ at absolute memory position (16r12345678*2+1) (*2+1 is to convert from SmallInteger to native representation of SmallInteger, marking it with the lowest bit in 1, similar to VisualWorks, but I think VW uses 2 bits instead of 1).

So, here’s another example. I could probably find more, but it’ll still be for VisualSmalltalk. If you are interested, I could take a look at anything else, but it’ll probably take me some time to find something.

Sorry for the long post

Yes. I’m pretty sure David’s S# and SmallScript VMs implement all his security mechanisms. Contact him for details. He’s on LinkedIn for example.

I’ve only given a quick diagonal read to your paper on “Context Management in VisualWorks 5i”, and it looks similar to what VisualSmalltalk does (not that I know all VS’ details).

Do you have a reference? I was under the impression that what I’d done for the context proxy mechanism was original. Does VS even have contexts?

One thing I can say is that in VisualSmalltalk is easy to demonstrate what I mean:

(Object >> #boom) byteCodeArray: #[2 19 72]

2 NoFrameProlog
19 PushSmallInteger0
72 Return

This will jump to native memory address 1 (SmallInteger 0). Manipulating this, an attacker can execute arbitrary native code, and that’s game over.

Right. But that requires that NoFrameProlog is in the instruction set. By bounds checking jumps at JIT-compile time and not providing instructions which allow one to jump to or return to arbitrary integers the bytecode can prevent executing arbitrary code. For that one would have to use the FFI

This is an example of the kind of native attacks on JITs that are most dangerous.

As I said, I still need to read your paper (have it on my loved kindle now :), and the other’s you referenced.

I wish I could be doing it too

Hi Richie,

I certainly hope there will be room for collaborators. I have to get my act together with a code repository and a bootstrap for a non-Qwaq image. Once this is done others will be able to get at the code.

Anyway, two comments:

When you say you are going to stick to a stack interface, I guess this is not 100% strict, and you are willing to go for tradeoffs such as passing receiver (and maibe first argument) in registers (eax and edx maybe?). Answers also in registers (maybe eax), and holding a reference to self in some other register (esi sounds good)? I have not done any performance test, but I think we don’t need to do them to demonstrate this gives a great performance boost, and IMHO it doesn’t break the stack abstraction too much (you only need to think that the top of the stack is held in eax

OK, I’ll go into this in more detail in another post but this is a most important point. The “interface” to the VM is still contexts. Internally the VM uses a stack for efficiency but this is (almost) completely transparent to the Smalltalk programmer who still sees only contexts. See this for a poorly written account of the details.

The calling convention will probably use Peter Deutsch’s convention for HPS which passed the receiver and last two arguments in registers. Using the last two makes the code generator simpler. This means that primitives like at: and at:put: don’t even touch the stack. The registers get pushed on method entry proper with a callee-saves convention.

On a different side, security is a huge issue, specially when it comes to JITs. For example, a very easy way to break out of the VM on a JIT is to unbalance the stack (when real and VM stacks are shared), if you push a constant and end the method, the return will just jump to the constant. This is a very clear case when arbitrary native code could be executed. Of course, if you are not thinking about security at all, and there’s not going to be no sandboxing, maybe the same could be done just injecting bytecodes.

Bytecode verifiers are one way to constrain this type of attacks, but they are not always enough.

I have some experience in security, and I’m willing to follow up on this if you are interested.

I’m very interested. Please do. Again much more details when I post on context-to-stack mapping, but I can say a little about the stack organization now. The VM’s Smalltalk stack will be housed on the C stack (created by alloca) but this is effectively sandboxed. One can only run bytecoded methods on the Smalltalk stack, bytecoded methods have finite stack, and calls on the Smalltalk stack are bounds checked. So I don’t think its possible to violate security through bytecode.

Eliot

I’m going to try to comment on Eliot’s comments o my comments without getting us all lost. GPS doesn’t work in here so good luck….

WRT CM format
“I think this is a problem of not seeing the wood for the trees The problem is not the format of CompiledMethod it is not being able to change it or subclass it”
Interesting point. Sure, let’s make it possible to add instvars to byte objects and word objects. Let’s add complexity to the classbuilder and debugger/inspector to support it. Is that actually simpler (remember you claimed to like TSTTCPW) than using the ‘normal’ class structures we already have? It would take some god arguments to convince me that it is so.

WRT ‘in-vm’ JIT or ‘in-mage’
I’m pretty sure that this -
“One important one is that of contexts. Contexts are a superb abstraction for activations, easing the implementation of processes, the debugger and so on. But they suck as a form for real execution”
does not actually logically imply this -
“So contexts belong in the image and clever tricks to do without contexts most of the time belong in the VM. But that implies that any code to do with hiding contexts belongs in the VM which implies that the lower levels of the code generator are in the VM.”
I don’t see why an in-image translator shouldn’t be allowed knowledge of the context handling, just as it is obviously allowed knowledge of the machine architecture. It doesn’t impact the debugger any more than an in-vm translator since you wouldn’t be debugging the generated code.
Further, one potentially very useful form of in-image translator would simply pass the relevant objects to a primitive (pretty much the same code as one might have in an in-vm translator) BUT it would allow the policy of what gets translated and when to be handled in the image. This might be of benefit in not ‘wasting’ time on translating code that is only run once, or it allow a choice between a quick-jit and a smart-jit at need. Or it might fail the prim completely on machines where there is no translator plugin yet provided or where the writable memory available on the machine is too small.
Having a separate machine providing translated results does not necessarily mean going over a network connection - it could be another thread on the same machine. Perhaps that would be a way of getting an aggregate speed boost from many-core systems - and of course one could do that with an in-vm translator too.
On some restricted systems it might be that performance or memory limitations prevent the system from being able to run a good translator and passing the work across a network is the better option. And on some other forms of restricted system it might be that there is read-only memory available that could be used to store cached translated code to some benefit.

Just offering some different views from odd angles.

tim

Oooh. Mmm I wonder caching at the central server? I wonder if you send hashs of the method if it could send back the cached compiled code, otherwise you send the code and get back compiled version. Obviously you can decide between using a common pool, or an agreed upon encryption for private usage.

Then for base squeak you could pre-load cached compiled code at startup time since global usage dictates a certain pattern

There is *no way* in which copying generated code over the network is going to beat generating fast code in a VM on the fly. No *way*. Have you looked at start-up times for VisualWorks? Note that even though the images Isaac Gouy runs on his shootout site take about 0.2 seconds to start-up that that time is dominated by walking the heap doing things like voiding old graphics handles, not in generating code. At least last time I looked compile time wasn’t the dominating factor. JITs can be very fast. Peter Deutsch’s figures were always around 20 machine instructions executed to generate a machine instruction. Even at one two or three orders of magnitude worse than that you’re going to slaughter copying code around the network. Fugedabahtid.

Eliot

I’d like to urge that you dump the stupid old compiled method format. After all, if you’re anticipating changing the definition of some bytecode and adding closures properly (at last!) tthen the image really isn’t going to be compatible with older vms. Besides, the current CM is total crap. It’s a bad idea from top to bottom and the hacks added in recent times, such as the properties array forced into the literals which are in turn etc etc just make it worse and worse. Clean it out! Traits broke the format as well, so far as the VM is concerned. So please, lets’ fix it properly and make the GC code simpler as well. Your great grandchildren will thank you.

Many years ago, Ian P was very excited about the performance enhancing possibilities of a cleaner CM design, claiming that having the bytecodes and literals as separate arrays would drastically simplify a translator. I’m not entirely sure I understood his arguments and of course they never had any practical value because he never finished anything that we could look at.

I think something like
Object subclass: #DecentCompiledMethod
instanceVariableNames: ‘header bytecodes literals properties’
classVariableNames: ‘ ‘
poolDictionaries: ”
category: ‘Kernel-Methods’
would be nearer the mark. I mean, just look at the current implementation of #methodClass. Or that old crap of fileIndex etc. Blech. Kill it.

I think this is a problem of not seeing the wood for the trees The problem is not the format of CompiledMethod it is not being able to change it or subclass it. But these limitations, not being able to add inst vars to CompiledMethod and not being able to subclass CompiledMethod are restrictions that only apply in the 16-bit BlueBook VM. The current Squeak VM is more than cabable of allowing CompiledMethod to be subclassed and to add inst vars to CompiledMethod and subclasses. It’ll take a bit of work in the ClassBuilder but no work in the VM. I have a post prepared on this but it is in the queue behind the next Closures post which is itself held up by my not being able (yet) to post the code. I don’t want the posts to get too bogged down in detail so they’re not the avenue through which to publish code (no one’s going to copy/paste code out of a blog post anyway!). Perhaps I should just post the message out of sequence.

Were you anticipating doing the translation under the covers within the vm as hps, or within the image? Or some other clever hack? I quite like the in-image idea as a general concept since it allows for a lot of flexibility. For example Bryce has had quite a lot of success writing a compiler that runs in the background, which is the ‘obvious’ approach. I’d like to see if having a remote compiler machine that you can send the method details to and get back a finished object might work. A local server image, or a remote one, or one that caches and can return almost immediately, or even one that submits it to Amazon’s mechanical turk could be tried. Another option would be to implement the translation as whatever needed mix of image code and plugin primitives; that would make it very easy to have a flexible system configurable at run time.

I like keeping as much stuff in the image as possible. But there are abstraction boundaries to maintain to keep a clean design. One important one is that of contexts. Contexts are a superb abstraction for activations, easing the implementation of processes, the debugger and so on. But they suck as a form for real execution. So contexts belong in the image and clever tricks to do without contexts most of the time belong in the VM. But that implies that any code to do with hiding contexts belongs in the VM which implies that the lower levels of the code generator are in the VM.

Cheers!
Eliot

tim
–
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim
Useful random insult:- One chicken short of a henhouse.

Thanks, Jecel.

Eliot