Default Integer Pointer Values

[Maurizio Cimadamore]

On 03/10/2019 15:26, Ty Young wrote:
>
> On 10/3/19 4:51 AM, Maurizio Cimadamore wrote:
>>
>> On 03/10/2019 05:12, Ty Young wrote:
>>> Hi,
>>>
>>>
>>> Recently I've stumbled upon a potential issue in regards to an 
>>> allocated integer pointer:
>>>
>>>
>>> Pointer<Integer> valuePointer = 
>>> <Lib>.scope().allocate(NativeTypes.INT);
>>>
>>>
>>> This basic integer pointer works fine of course. However, for some 
>>> reason the pointer has a value already set despite never been given 
>>> one. In potential functions that don't have proper return code 
>>> values(enums, technically), these values could be potentially seen 
>>> as valid values when in reality they are not. In some cases I think 
>>> these values can even change from run-to-run, making the issue even 
>>> worse.
>>>
>>>
>>> Would the expected behavior here not be to have the wrapped value be 
>>> NULL or is there reasons as to why it does this?
>>
>> Currently, when we allocate memory we do not zero it - which is why 
>> you are seeing what you are seeing, I believe.
>>
>> I agree that we will need to go there - but we're looking at ways to 
>> do the zero-init that are more efficient as the current techniques 
>> (Unsafe.memorySet) are excessively punitive on large allocations. 
>> There was some discussion on this some time ago:
>>
>> https://mail.openjdk.java.net/pipermail/panama-dev/2019-January/003773.html 
>>
>>
>> I'm trying (among the other things) to pick this up again, and see if 
>> some better solution can be achieved here.
>>
>
> System memory isn't automatically zeroed at de-allocation? Wouldn't 
> that be a potential security risk similar to quick formatting a drive?
>
>
> Nvidia GPUs don't and you can see frame buffer images from hours ago 
> under Linux sometimes which seems kinda dangerous. I always assumed 
> system memory was treated better in that regard.

This is obviously not the path we want to take for Java, don't worry :-)

Memory will always be zeroed accordingly - but for now we are trying to 
explore what's the best way to do that.

>
>
> I take it the reason no one does it is because of the general 
> performance impact it would have, yes?

If you do it the naive way using memset, performance is a problem, yes.

That said, if we can't speed that up significantly using other 
approaches, we will make things secure the 'standard' way. This is on my 
todo list for loose ends of the memory access API; whatever we discover 
there will be forward ported to the Pointer API.

Maurizio

>
>
> Thanks for the answer.
>
>
>> Maurizio
>>