I agree with Gil on this point. `PhantomReference::get` always returns
null. The intent behavior of `ref.refersTo(obj)` is the same as
`ref.get() == obj`. Gil's proposed option to have `refersTo(obj)` to
return true only if obj is null is a reasonable one.
If `PhantomReference::get` were to change to have the same behavior as
other references some day, then `PhantomReference::refersTo` would be
updated at that time (but no proposal doing that at the moment).
Mandy
On 4/8/20 9:05 AM, Gil Tene wrote:
Lifting out of response from the JIRA issue:
I always worry when proposing a change to an existing invariant, and
PhantomReference currently carries the stated and specified behavior
of "the referent of a phantom reference is always inaccessible".
I can imagine quite a few forms of gaining new information I do not otherwise
have access to by using PhantomReference::RefersTo if it allowed me to examine
the current referent of a phantom reference and test to see if it is (a) null
or (b) a
specific object I have a reference to. Both of those would provide me with
information
that is impossible for me to get according to current specifications. With that
newly
available information one can come up with all sorts of nice things to do...
Think in
terms of "side-channel" as an example of the sort of thinking black hats can
apply
to this new knowledge, but the potential attacks are not limited to
side-channels.
While it will be "obviously safe" to have Reference:RefersTo(obj) provide the
same
information that (Reference.get() == obj) would, providing more information than
that would be a change to the specified behavior of Reference types, which we
should be extra paranoid about. Since PhantomReference::get returns null by
definition, we should remain consistent with that in PhantomReference::refersTo
On Apr 8, 2020, at 7:56 AM, Erik Österlund <erik.osterl...@oracle.com> wrote:
Hi Gil,
Lifting out my reply to you from the JIRA issue:
In terms of breaking existing logic, I am not worried. This is a new API, that nobody is
using yet. People that write new code that uses it, will have to pay attention that they
are doing the right thing. We are still not exposing the phantom referent with this
change. In terms of security, you can only use this API to figure out what the referent
is, if you already have access to it. So that isn't really helpful for building exploits.
What it could do is allow you to check which one of N objects that you already have
access to is the one referred to from the PhantomReference. But in terms of security, you
could also have just guessed that without this API, as you already have full access to
the objects. Sounds like a classic case of "I have an exploit. Given a compromised
system... X". Or have I missed something?
Thanks,
/Erik
On 2020-04-08 16:25, Gil Tene wrote:
A very welcome change overall. However, I have concerns about
the semantic change to the PhantomReference specification. I propose
that PhantomReference semantics remain unchanged, and that
PhantomReference:RefersTo should return true only for null.
See more in comment at
https://bugs.openjdk.java.net/browse/JDK-8188055?focusedCommentId=14329319&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14329319
On Apr 7, 2020, at 5:25 PM, Kim Barrett <kim.barr...@oracle.com> wrote:
[Note review on both core-libs and hotspot-gc-dev lists; try not to lose
either when replying.]
Please review a new function: java.lang.ref.Reference.refersTo.
This function is needed to test the referent of a Reference object
without artificially extending the lifetime of the referent object, as
may happen when calling Reference.get. Some garbage collectors
require extending the lifetime of a weak referent when accessed, in
order to maintain collector invariants. Lifetime extension may occur
with any collector when the Reference is a SoftReference, as calling
get indicates recent access. This new function also allows testing
the referent of a PhantomReference, which can't be accessed by calling
get.
The new function uses a native method whose implementation is in the
VM so it can use the Access API. It is the intent that this function
will be intrinsified by optimizing compilers like C2 or graal, but
that hasn't been implemented yet. Bear that in mind before rushing
off to change existing uses of Reference.get.
CR:
https://bugs.openjdk.java.net/browse/JDK-8188055
https://bugs.openjdk.java.net/browse/JDK-8241029 (CSR)
Webrev:
https://cr.openjdk.java.net/~kbarrett/8188055/open.04/
Testing:
mach5 tier1
Locally (linux-x64) verified the new test passes with various garbage
collectors.
