RFR: 8188055: (ref) Add Reference.refersTo predicate

[Mandy Chung]

On 8/25/20 10:11 PM, Kim Barrett wrote:
> Finally getting back to this after some internal discussion that
> dragged along because folks have been busy.
>
>> On Apr 8, 2020, at 12:05 PM, Gil Tene <gil at azul.com> 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
> [copied from JIRA issue]
> That all assumes that I'm giving you access to my phantom references.
> But if I'm doing that then I've got much worse problems than any
> potential information leakage of the kind being suggested. If you have
> one of my phantom references then you can enqueue it, triggering any
> associated cleanup while I'm still using the referent. One should not
> give one's phantom references to untrusted code. That's nothing new,
> and is not made any worse by having Reference.refersTo work the same
> way for phantom references as for other reference types.
>
>

Agree.    We should probably document this in the Java security code 
guideline to advice the developers be cautious and not to leak Reference 
objects.

Mandy