[9] RFR(M): 8076112: Add @HotSpotIntrinsicCandidate annotation to indicate methods for which Java Runtime has intrinsics

John Rose john.r.rose at oracle.com
Mon Jun 29 20:47:41 UTC 2015


On Jun 29, 2015, at 10:48 AM, Doug Simon <doug.simon at oracle.com> wrote:
> 
> As I understand it, part of this change is to split intrinsification into one method that does the checks that then calls a second method which the VM may intrinsify on the assumption all checks have been performed by the first method. What’s to prevent a direct call to the latter via reflection that by-passes the first method?

The answer is simple:  We mark the dangerous method private.

I assume you are thinking about setAccessible, but if that's allowed there's nothing to prevent people from taking whole system down in a hundred different ways.  At that point having a surprising intrinsic is the least of our problems.

> I understand that writing the checking logic in Java is desirable. 

Indeed, that is the key compromise here.  Coding the required checks in assembly code or compiler IR is (as we all know) a losing battle.  You need Maxine/Graal snippets or real Java code to get it right.

— John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20150629/f7010931/attachment.htm>


More information about the security-dev mailing list