On Mon, 25 Feb 2019 at 13:06, Peter Maydell <peter.mayd...@linaro.org> wrote: > > On Mon, 25 Feb 2019 at 12:22, Natanael Copa <nc...@alpinelinux.org> wrote: > > > > On Mon, 25 Feb 2019 10:34:23 +0000 > > Peter Maydell <peter.mayd...@linaro.org> wrote: > > > The short term fix is to fix your toolchain/compilation > > > environment options so that it isn't trying to override > > > the definition of memcpy(). > > > > The easiest workaround is to simply disable FORTIY_SOURCE, but that > > will weaken the security for all implemented string functions, strcpy, > > memmove etc, so I don't want to do that. > > > > Is it only lduw_he_p that needs to be atomic or are the other functions > > in include/qemu/bswap.h using memcpy also required to be atomic? > > Hard to say, since we haven't done the "audit all the callers" > step that Stefan mentioned. If you're going to replace memcpy > with __builtin_memcpy then the safest thing is to do it for > all those uses (this will also give you much better generated > code for performance purposes).
I mentioned this to Richard on IRC the other day, but I think there's a good argument for making upstream QEMU use __builtin_memcpy in these helpers: * it makes us robust against things like this fortify library in the short term (until we fix QEMU to have an equivalent set of functions for doing atomic accesses to AddressSpaces) * in the longer term it will mean that we don't end up with these functions being really badly-performing even if the semantics of the out-of-line memcpy() are correct thanks -- PMM
