On 08/16/2014 12:39 AM, John Rose wrote:
On Aug 15, 2014, at 5:03 AM, Florian Weimer <fwei...@redhat.com> wrote:
On 08/14/2014 10:15 PM, Mark Roos wrote:
Look into sun.Misc.Unsafe
[and at defineAnonymousClass(Class, byte[], Object[])]
Thanks. Could we turn this into a supported API, with a suitable security
manager check?
Hi Florian and Mark.
Here's the story about that.
Unsafe.defineAnonymousClass is used inside the JDK for loading small classes of
indeterminate lifetime. Many of them contain single static methods, which
makes it, in effect, an anonymous method loader.
Because the small bits of code often need to be injected into a pre-existing class, a
"host class" can be designated, which means the anonymous class has access to
everything the host class can access, including host class privates.
Because the small bits of dynamically generated code can depend on (meta-)data values that are
dynamically computed and/or are anonymous, the class's constant pool can be "patched" to
refer to "live" values that do not have symbolic names.
So it allows some low-level tinkering with the JVM internals. Like any
non-standard internal API, if you use it, you are tightly coupled to the JVM
implementation, and you are on your own if something goes wrong. We fix bugs
in this internal feature only if it fixes a bug in a standard J2SE feature that
somehow depends on it.
I expect that defineAC and its use cases will help inform future consideration of
next-generation class loading APIs. I don't expect it to become a standard feature on
its own. For one thing, the design is "not quite right": It should really be
a method loader, but we don't have a separate format for methods. The constant pool
patching part of the API, while necessary, requires knowledge of constant pool layout,
which feels wrong too.
Specifically, in the context of a (not yet existing) "classfile 2.0" effort,
defineAC should help us think about the format of a stand-alone method, about the
interaction of packaging and access rights, and about the division of labor between
constant pool and bytecode. Since these are (to my mind) open-ended design questions, I
don't think we will promote the existing ad hoc API to a public one, unless there is a
compelling short term reason to do so.
The most obvious security interaction is with the host-class feature; as it
stands the API is very unsafe because you could use it to inject code into any
system class.
Just allowing the existing API with a security manager check is too
coarse-grained to make the feature useful, except to highly trusted code.
If the host-class token were changed to a MethodHandles.Lookup object, we could
restrict the host-class to be one which the user already had appropriate access
to. Seems simple, but of course the rest of the project is complicated: API
design, spec completion, security analysis, positive and negative test
creation, code development, quality assurance—all these would be expensive, and
(again) most easily justified in the context of a larger refresh of our
classfile format.
Do you have a use case in mind that could be expressed as a more tightly
focused API? It might be easier to standardize on a very specific API that
used dAC.
Or, most or all of dAC could be simulated using regular class loading, into a
single-use ClassLoader object. The nominal bytecodes would have to be
rewritten to use invokedynamic to manage the linking, at least to host-class
names. But given that ASM is inside the JDK, the tools are all available.
(Remi could do most of it in an afternoon. :-) ) Given such a simulation, the
internal dAC mechanism could be used as an optimization, when available, but
there would be a standard (complex) semantics derived from ordinary classes and
indy.
https://gist.github.com/forax/0c25deac1867d1ef3247
— John
Rémi
I'm surprised there aren't any callers of this method in Fedora. Anonymous
classes look very useful for run-time code generation.
--
Florian Weimer / Red Hat Product Security
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
