On 09.09.2011 03:00, John Rose wrote:
On Sep 8, 2011, at 5:35 PM, Thomas Wuerthinger wrote:
The operand stack and locals manipulation in the generated bytecodes
must exactly match the manipulations done by the scripting
interpreter, but I think that it is possible to align those (although
there might be some complexity due to the fact that certain value
types require more than 1 stack slot). The safeAdd method could be
intrinsified to deoptimize to the Java interpreter. So, in case an
overflow occurs, there would be a two-level deoptimization: Java
optimized code => Java interpreter (which now actually throws the
DeoptimizationException) => Scripting language interpreter.
Got it. I had missed the meaning of your phrase "at the JVM-level (in
fillInStackTrace)". So the exception has an extra-heavy backtrace.
Yes, exactly.
The backtrace amounts to a JVM continuation. Is there a way to do
data hiding so that the language runtime can only see locals that it
has a right to observe?
That IMO is the problem with rich backtraces: They provide a very
deep punch into the JVM, which can be exploited (like reflection) to
break across trust boundaries.
I guess one answer is that we could trust language runtimes. I'd
rather find a more compartmentalized solution, hence my interest in
patterns expressible in current bytecodes.
If this special exception class is declared as a checked exception, a
method would itself chose if its stack is exposed or not based on its
"throws" clause. I think in that case the possible exploitations are
less than reflection (because it would not be possible to access data
declared "private", but only the stacks of methods that are explicitly
declared accessible). That this is a first step towards continuation
support would be a nice side effect of this solution.
- thomas
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
