On 12/14/25 17:50, Andrew Cooper wrote: > On 14/12/2025 7:09 pm, Demi Marie Obenour wrote: >> I noticed that libxenvchan has undefined behavior: it passes pointers >> to guest memory to memcpy() even though they can be concurrently >> changed. >> >> Would it make sense to reuse some of Xen's copy_from_guest() code >> instead? There might be a licensing problem (GPL vs LGPL), though. >> I think the only approach that isn't UB and has decent performance >> is to do the whole copy in assembly. > > memcpy() is well defined.
Rich Felker wrote otherwise on the musl mailing list. Specifically, it is undefined behavior if the data is changed while memcpy() is accessing it, either for reading or for writing. > The problem is the potential for creating TOCTOU races if suitable > barriers aren't used, due to the compiler being able to optimise through > memcpy(). The concern here is about races in memcpy() itself. > Xen's copy to/from guest are not appropriate in userspace. They're > guarding against pagefaults and address ranges not belonging to the > target context. > > If more compiler/smp barriers are needed, then that's the appropriate fix. Rich Felker suggested to use an open-coded memcpy() that used volatile accesses. -- Sincerely, Demi Marie Obenour (she/her/hers)
OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
