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

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Wed Jul 3 11:22:47 UTC 2019


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