[CLOSED] LDC instruction with String constant

[aionbot]

Issue created by yulongaion (on Friday May 11, 2018 at 20:19 GMT)

An ldc instruction with operand CP is type safe iff CP refers to a constant pool entry denoting an entity of type Type, where Type is either int, float, String, Class, java.lang.invoke.MethodType, or java.lang.invoke.MethodHandle, and one can validly push Type onto the incoming operand stack yielding the outgoing type state.

TODO: apply type shadowing for the reference type

[aionbot]

Comment by jeff-aion (on Monday May 14, 2018 at 14:27 GMT)

We can't change the type instantiated by the JVM when loading the class but we do still want to limit access to these "real" types, within the contract code.
It would be relatively easy to wrap these via an instrumentation call to a static helper. The instance type check could even be done within the helper and the call to the helper would only add a single bytecode after the ldc (since lcd pushes the value on the stack but invokestatic pops its argument and pushes its return value - net effect being no change in the stack shape).
We just need to look into the cases where the ldc is used to make sure that there aren't any cases where we must not wrap the type loaded.

[aionbot]

Comment by romaion (on Monday May 14, 2018 at 14:33 GMT)

Note that 'foo' code below compiles to ldc as well.

public class ClassA {
    void foo() {
        var statRef = ClassB.class;
    }
}

class ClassB {
}

void foo();
descriptor: ()V
flags: (0x0000)
Code:
stack=1, locals=2, args_size=1
0: ldc #2 // class org/aion/avm/testcontracts/ClassB
2: astore_1
3: return

---

[aionbot]

Comment by jeff-aion (on Monday May 14, 2018 at 14:45 GMT)

Yes, that is another case where we probably want to wrap it with our shadow Class implementation. I am worried about needing to do more complex flow analysis (might not even be solvable without us imposing some restrictions) to handle some of the types involved in method invocation.

[aionbot]

Comment by jeff-aion (on Monday May 14, 2018 at 15:29 GMT)

Reading through the documentation for MethodType (seems to be used with invokedynamic) and MethodHandle (seems to be used with reflection), it sounds like those types can be rejected by our use-case, instead of handled.
This means that we should be able to statically inject an invokestatic for either the String or Class cases, fail on MethodType or MethodHandle, and change nothing on the primitive constant cases.