RFR (S) 8150465: Unsafe methods to produce uninitialized arrays
Jim Graham
james.graham at oracle.com
Thu Feb 25 22:57:50 UTC 2016
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.
>
More information about the jdk9-dev
mailing list