Re: Undefined behavior in libxenvchan

[Jan Beulich <jbeulich@suse.com>]

On 15.12.2025 00:08, Demi Marie Obenour wrote:
> 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.

Aren't you talking about undefined-ness beyond what the C spec uses the
term for? Of course it is always unpredictable what the result of a
function will be when you fiddle with its source behind its back. But
that's not of concern as far as safety is concerned (while the
correctness issue that results is solely a problem for the party doing
the undue modifications).

What we need to guarantee is that whatever copy is made of whatever
in-flight data, any sanity and consistency checking as well as subsequent
use would take only the one, exact same copy of source data. Which, as
Andrew said, may require some extra barriers, while using memcpy() for
the mechanical copying ought to be okay.

Jan

>> 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.