[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