[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-2d-dev
Subject:    Re: [OpenJDK 2D-Dev] [9] Review Request: 8080847 Copying of overlapping memory should be improved in
From:       Phil Race <philip.race () oracle ! com>
Date:       2015-05-29 22:16:49
Message-ID: 5568E551.3060207 () oracle ! com
[Download RAW message or body]

I've asked around internally and the overwhelming
consensus is that memcpy is not dangerous in
the overlapping case. Our security/vulnerability
expert does not see a problem - as long the
pointers are valid of course.
The long-ago author of the memcpy man page
surely meant that the end resulting bytes in memory
are up to the platform in this case to make
optimisations that won't follow the same pattern
as other platforms, not that the library call has a license
to do bad things.

The corollary to that is that the change to use
memmove is not really making things safer, and
without more changes is not making the code
usefully predictable.

A little research (and there could be more done)
shows that XCopyArea makes no promise about how
it handles such a case, whereas glCopyPixels
does specify the order it copies, of course whether it
results in the same output has having used
an intermediate buffer depends on the
specifics of your source and destination and
we are not going to be able to specify what
happens since we rely on pipelines that we
cannot control.

-phil.

On 05/29/2015 01:09 AM, Andrew Haley wrote:
> On 28/05/15 21:33, Jim Graham wrote:
>> The only viable reason for switching to memmove is to either silence the
>> tool that reported the issue or to fix the data ordering issue.
> Or to remove the UB.  Your opinion that UB is constrained is wrong in
> principle and dangerous in practice.  It is extrememly unlikely that
> moving to memmove() will result in perciptible difference; I can't see
> any reason not to simply fix your code.
>
>> There are other ways to silence the tool without making one of our
>> blits have behavior that doesn't match other similar blits, and if
>> we are going to fix the data ordering issue we should do it for all
>> blits...
> Indeed.
>
> Andrew.

[prev in list] [next in list] [prev in thread] [next in thread]