#501 Fixing the glibc adobe flash incompatibility
Closed None Opened 13 years ago by jwrdegoede.

= Proposal topic =

A recent glibc update has broken the adobe flash plugin and the glibc maintainers are refusing to fix this.

= Overview =

A recent glibc update has broken the adobe flash plugin and the glibc maintainers are refusing to fix this. I'm about to start a discussion about this on fedora-devel and I would like FESCo to look into this during one of our next meetings. I believe this makes us look bad, and the glibc maintainers do not look like they are going to do anything about this without intervention.

Here is a copy of the mail I'm about to send to fedora-devel:

Hi,

For those who do not know it yet, recent Fedora glibc updates include
an optimized memcpy (which gets used on some processors) which breaks the
64 bit adobe flash plugin.

The problem has been analyzed and is known, as well as a fix for it, see:
https://bugzilla.redhat.com/show_bug.cgi?id=638477

The problem still exists however. The glibc developers say that this is
not a glibc bug, but a flash plugin bug. And technically they are 100%
correct, and the adobe flash plugin is a buggy .... (no surprise there).
To be specific the flash plugin is doing overlapping memcpy-s which is
clearly not how memcpy is supposed to be used. But the way the flash
plugin does overlapping memcpy's happens to work fine as long as one as
the c library does the memcpy-s in forward direction. And the new memcpy
implementation does the memcpy in backward direction.

The glibc developers being technically 100% correct is not helping our
end users in this case though. So we (The Fedora project) need to come up
with a solution to help our end users, many of whom want to use the adobe
flash plugin.

This solution could be reverting the problem causing glibc change, or
maybe changing it to do forward memcpy's while still using the new SSE
instructions, or something more specific to the flash plugin, as long
as it will automatically fix things with a yum upgrade without requiring
any further user intervention.

I would also like to point out that if this were to happen in Ubuntu
which we sometimes look at jealously for getting more attention / users
then us, the glibc change would likely be reverted immediately, as that
is the right thing to do from an end user pov.

I've filed a ticket for FESCo to look into this, as I believe this
makes us look really bad, and the glibc maintainers do not seem to be
willing to fix it without some sort of intervention:
<url to fesco ticket>

Regards,

Hans


A recent glibc update has broken the adobe flash plugin and the glibc maintainers
are refusing to fix this.

And they're right:
* This is a bug in Flash. glibc is entirely the wrong place to fix it.
* This is a bug in proprietary software. We do not support proprietary software.
* Adding such workarounds can hurt Free Software users by degrading performance.
* Adding such workarounds removes the incentive for Adobe to fix their code.
* Adding such workarounds removes the incentive for considering Free alternatives to Flash.

We should not work around Adobe's bugs. Any complaints about the breakage should be sent to Adobe.

However, it would be nice if glibc warned about overlapping memcpy since it's clearly used in applications instead of silently breaking them. That has also been suggested in the bug. Clearly it's technically correct to shrug this off as "not our problem", but IMHO reverting memcpy change and adding a warning for, say, one Fedora release wouldn't hurt anyone, but give us the opportunity to say: "See, we've been warning you for 6 months. Don't cry now." Instead of the current uproar.

The problem is that range checking all memcpy operations wastes a lot of CPU cycles. For short memcpy operations, it can even take longer than doing the copy in the first place!

as mentioned the glibc maintainers are correct it is not a bug in glibc. However being right does not solve the problem from the users point of view. The correct answer in the case is to revert the change in glibc until such time as Adobe issues a fix or another work around is found.

We might not all like the use of proprietary software, but it is a fact of life that it is out there and our users want to use it,so we have to support it.

Fedora has never supported proprietary software, why should we now suddenly "have to support it"?

Those users out there can use one of several workarounds which do not require modifying Fedora packages for that third-party bug:
* Just use the 32-bit version. (FYI, that's still the only one considered stable by Adobe and offered through Adobe's YUM repository.) That's what nspluginwrapper is for.
* LD_PRELOAD another implementation of memcpy, such as the Linus one (as posted to the bug report).
* Use that script (also posted to the bug report) which patches the binary to use memmove instead of memcpy everywhere.

It's really not the job of our glibc (or nspluginwrapper, xulrunner etc.) maintainers to work around this bug in their non-buggy packages!

I meant to add this to the agenda for the meeting today, but it slipped through the cracks. ;( Sorry about that.

I've reopened the bug and asked the glibc maintainers to reconsider based on the technical arguments.

We are not going to force them to revert this however. It's up to people to provide good technical arguments that convince them.

Login to comment on this ticket.

Metadata