Fixing the glibc adobe flash incompatibility
mrsam at courier-mta.com
Thu Nov 18 04:21:10 UTC 2010
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
>> 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
> 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
> 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
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20101117/1cf762f0/attachment.bin
More information about the devel