Chris Adams writes:
Once upon a time, Sam Varshavchik <mrsam@xxxxxxxxxxxxxxx> said:Fulko Hew writes: >I know the definition for memcpy (on Linux) says don't use overlapping >regionsNo, 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.
Attachment:
pgpY936GRBD6v.pgp
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
