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

Peter Levart peter.levart at gmail.com
Mon Aug 17 14:57:16 UTC 2020

On 8/17/20 2:55 PM, Michael Kuhlmann wrote:
> 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.
Yeah, you can do it if you are evil and have access to Unsafe also. This 
is not a security concern. It is a concern that otherwise kind people 
will start abusing the API to code useful programs that will later fail 
when the information API suddenly starts returning "unknown" values.

Regards, Peter

More information about the jdk-dev mailing list