Fixing the glibc adobe flash incompatibility

nodata lsof at nodata.co.uk
Wed Nov 17 22:11:29 UTC 2010


On 17/11/10 22:16, John Reiser wrote:
> On 11/17/2010 12:41 PM, Emmanuel Seyman wrote:
>> 2) Issues found in proprietary software cannot be fixed by anybody except
>>     the vendor
>
> False.  In this particular case, it is possible to binary edit the plugin
> libflashplayer.so so that all its calls to memcpy become calls to memmove.
> The change is to copy the .st_name field from the symbol for memmove to the
> .st_name field of the symbol for memcpy, which creates another instance
> of memmove.   With that one 32-bit change, then the player will work.
> Memmove can be a few percent slower than memcpy, but nobody will notice.

Editing binaries is a bad idea and also breaks the packaging guidelines.

rpm verification will also break. It sets a bad precedent.

> If the plugin did not have a reference to memmove already, then on x86_64
> an impostor can be created by introducing the name "memmove\0" at
> &{DT_NULL}.d_un.  This is a generic work-around for this particular
> issue with memcpy on x86_64.
>



More information about the devel mailing list