[foreign-memaccess] RFR 8227107: Add missing toString implementation to MemorySegmentImp

Sundararajan Athijegannathan sundararajan.athijegannathan at oracle.com
Wed Jul 3 12:02:36 UTC 2019


Looks good.

-Sundar

On 03/07/19, 4:53 PM, Maurizio Cimadamore wrote:
> Webrev: http://cr.openjdk.java.net/~mcimadamore/panama/8227107_v2/
>
> Maurizio
>
> On 03/07/2019 12:22, Maurizio Cimadamore wrote:
>> Here's another version of the webrev which creates a random segment id.
>>
>> It does that by hashing (via Objects.hash) a random nonce (which 
>> changes on every VM execution), the segment address and the hash of 
>> the segment base object (if any).
>>
>> The absolute value of the result is computed, so that we get some 
>> positive number (we don't really care about collisions here as much 
>> as we do for obfuscation).
>>
>> This gives an ID which should be pretty innocuous, but useful in most 
>> debugging cases.
>>
>> Thoughts?
>>
>> (I deliberately wanted to avoid dependencies on heavier crypto APIs, 
>> given that this code eventually will live in java.base; I could of 
>> course recover some of the murmur hash32 stuff that was dropped as 
>> part of this changeset [1], but maybe simpler is better here?)
>>
>> [1] - http://hg.openjdk.java.net/jdk/jdk/rev/a24e00a7c5ae
>>
>> Maurizio
>>
>> On 02/07/2019 22:08, Maurizio Cimadamore wrote:
>>>
>>> On 02/07/2019 21:58, John Rose wrote:
>>>> On Jul 2, 2019, at 9:29 AM, Maurizio Cimadamore 
>>>> <maurizio.cimadamore at oracle.com 
>>>> <mailto:maurizio.cimadamore at oracle.com>> wrote:
>>>>>
>>>>> toString() method can't reveal sensitive pointer info
>>>>
>>>> I wonder if there is a way to sanitize the pointer value, into a 
>>>> hash code.
>>>> Some JVMs use the raw object address as an input to the identity 
>>>> hash code.
>>>> We could do something similar.  The hash could be kept small, to 
>>>> (say) 5 hex digits,
>>>> and would serve to separate the segments for debugging purposes.
>>>> Since the default Object.toString does something like this I'm 
>>>> thinking we could
>>>> emulate that.
>>>>
>>>> (How to hash the address?  First take a 64-bit address and another 
>>>> 64 bits of
>>>> nonce secret to the current JVM instance.  Then mix them together, 
>>>> using
>>>> xxhash or a similar algorithm.  Then throw away all but a few, say 
>>>> 20, bits
>>>> of result.  The result will provide no useful information to 
>>>> attackers, other than
>>>> a likely discrimination between different base pointers.)
>>>>
>>> That's a nice suggestion!
>>>
>>> Maurizio
>>>
>>>>
>>>>
>>>>


More information about the panama-dev mailing list