Fixing the glibc adobe flash incompatibility

[Sam Varshavchik]

Chris Adams writes:

> Once upon a time, Sam Varshavchik <mrsam at courier-mta.com> said:
>> Fulko Hew writes:
>> >I know the definition for memcpy (on Linux) says don't use overlapping
>> >regions
>> 
>> No, the definition for memcpy on Linux does not say that. What says that is 
>> the POSIX specification. Which is called a "standard".
> 
> Just for kicks, I pulled my K&R (ANSI edition) off the shelf, and it
> says the same thing.
> 
> However, I still think that changing memcpy away from years of "it just
> works" is an ABI change that should not be taken lightly and IMHO

POSIX specifies memcpy's ABI. Both the previous implementation and the 
current glibc implementation of memcpy() is compliant with the defined ABI.

> shouldn't be done in a "stable" release of glibc.  Is memcpy called
> often enough (and on large enough blocks) that this change makes a real
> performance difference (not just on a synthetic memcpy benchmark)?

According to others, it seems to make a difference on some, but not all 
CPUs.

> A change like this could even introduce security bugs in code that was
> formerly working.

No, it would not introduce or create a new security bug. But it would expose 
an existing security bug in the code. The difference is very subtle, but 
important.

> This is also especially annoying when the change may not really make
> difference in performance (according to Linus' test).

Linus also provided a very trivial way to remediate it. Which even works 
with binaries that cannot be rebuilt, like the subject matter of the thread 
subject.

If such a trivial workaround was not available, then I'd be more inclined to 
agree that reverting the glibc change would carry more weight. But, so far, 
the biggest impact seems to be flash blob. For which the solution exists.

It would be worthwhile to use Linus's approach to wrap memcpy() into a stub 
that detects if an overlapping memory region was passed, then abort(), 
shoving it into LD_PRELOAD globally (including initscripts), then see what 
breaks.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20101117/1cf762f0/attachment.bin