RFR (S) 8150465: Unsafe methods to produce uninitialized arrays

[Jim Graham]

Just to play devil's advocate here.

It's true that from a code correctness-safety perspective Unsafe 
programmers can already shoot themselves in the foot with uninitialized 
allocations, but from the security point of view the two methods don't 
have the same opportunity to leak information.

Unsafe.allocateMemory returns a long, which is just a long to any 
untrusted code since it can't use the Unsafe methods to access the data 
in it.

The new uninitialized array allocation returns a primitive array which 
can be inspected by untrusted code for any stale elements that hold 
private information from a previous allocation - should that array ever 
be leaked to untrusted code...

			...jim

On 2/25/2016 7:47 AM, Paul Sandoz wrote:
>
>> On 25 Feb 2016, at 15:36, Aleksey Shipilev <aleksey.shipilev at oracle.com> wrote:
>>
>> On 02/25/2016 05:13 PM, Andrew Haley wrote:
>>> On 02/25/2016 01:44 PM, Aleksey Shipilev wrote:
>>>> Of course, you will still see garbage data if after storing the array
>>>> elements into the uninitialized array you would publish it racily. But
>>>> the same is true for the "regular" allocations and subsequent writes.
>>>> The only difference is whether you see "real" garbage, or some
>>>> "synthetic" garbage like zeros. It is, of course, a caller
>>>> responsibility to publish array safely in both cases, if garbage is
>>>> unwanted.
>>>
>>> Of course, my worry with this optimization assumes that programmers
>>> make mistakes.  But you did say "complicated processing is done after
>>> the allocation."  And that's where programmers make mistakes.
>>
>> Of course they do; at least half of the Unsafe methods is suitable for
>> shooting oneself in a foot in creative ways. Unsafe is a sharp tool, and
>> Unsafe callers are trusted in their madness. This is not your average
>> Joe's use case, for sure.
>>
>
> FTR the contents of the memory allocated by Unsafe.allocateMemory are also uninitialized.
>
> Paul.
>