RFC (round 1), JEP draft: Low-level Object layout introspection methods

[Michael Kuhlmann]

On 8/17/20 2:33 PM, Aleksey Shipilev wrote:
> On 8/16/20 12:41 PM, Peter Levart wrote:
>> On 8/11/20 12:22 PM, Aleksey Shipilev wrote:
>>> ...but dislike:
>>>       public static long addressOf(Object obj);
>>>       public static long fieldOffsetOf(Field field);
>> What exactly is the purpose of "addressOf" method in terms of
>> information API? Is it used to estimate relative placement of several
>> objects in the heap to see how they are scattered around which affects
>> the CPU cache performance when accessing them?
> Yes, it says so in "Motivation" section in JEP. Additionally, checking the object address against
> the cache line size.
>
>> If this is the case, then maybe the method could return a "mangled"
>> address: the address + some secret random value calculated once for the
>> whole VM.
> Now that is an interesting suggestion!
>
> Implemented here:
>    https://hg.openjdk.java.net/jdk/sandbox/rev/248807bfa78e
>
> There is little-to-none loss of performance, because the offset can be trivially used in intrinsics.
> JEP text is updated to mention this technique. I believe this makes the address exposure story less
> problematic, although the result is still conceptually a useful proxy for a memory location.
>

I don't fully get it. If the idea is that evil attackers shouldn't be 
able to read confidential information from Java objects, then adding a 
secret offset won't help. You can just create a unique object, e.g. an 
array filled with some data, and scan the whole heap for that. Then you 
can easily calculate the distance between this and any other object and 
read or modify its content.