Your countermeasure would do nothing to affect the security of the JVM. The problem is with the in-memory code being modified after the type checking is done. This would allow untrusted code to pass invalid data to trusted code, thus comprimising the JVM. Very similar to buffer overruns.
The best your solution would allow is: "Oh oh, memory has been corrupted. Guess I'll stop". Not very good behavior for a smartcard
Sorry if the above doesn't make much sense. I need to get some sleep.
Slashdot Mirror
Your countermeasure would do nothing to affect the security of the JVM. The problem is with the in-memory code being modified after the type checking is done. This would allow untrusted code to pass invalid data to trusted code, thus comprimising the JVM. Very similar to buffer overruns.
The best your solution would allow is: "Oh oh, memory has been corrupted. Guess I'll stop". Not very good behavior for a smartcard
Sorry if the above doesn't make much sense. I need to get some sleep.