[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Undefined behavior in libxenvchan
- To: Demi Marie Obenour <demiobenour@xxxxxxxxx>, Xen developer discussion <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
- Date: Sun, 14 Dec 2025 22:50:37 +0000
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=D0wnGqpTRdLHwdi/rtzktp+W+Cx0CT0bsqk74y8suo0=; b=I3BrN1sTkKcBBGh3U3nbKBfUzJW/lxRr1C9BUyRpAUwcvF1v8cD+4ITUx40fidxS8is+8TFM2b/C53qez1khLphnfOcZBD9GjW78wNCPBOtY5j4Rw+0p+TWgyQiJpDInhZl/sQpKBMXL6DfqNkyuSlhmc1GwMNSF/1lGNl2nTNImiNEFl9RrDVzr5zPZEvIE8f1tbLRIu+69BhdDVfOr0YMtwHS8JHpKeIcMyogQfrXHhW4+MLbGslqJAGlWE5QpVSC6/puCLCBJfb1iLONNRCVECp5LG3I9c+AC+4CRoLWbl6+RfJa7LyiK68LN29nXskA7xqHtVTd0lF1tKeK9nA==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=POyerOVFp9Z/EorRvkCPkMn+DhvxUPk15ruCf3ccJpzdTIXHEqKELbFhUyt6BHO1nApnpU9/KnULBOVxKq3Wf+Ym9n8lUe3PHQqqc0T9fxRAl5/djx6duG0Dh2AyLPWpcIjzFyl7lfL/VvZhmv9kac6DALsacSgmWtcM97iQ+XLi8EROXMvAXNY27kljr8oXSO6X3ldBxkr63Drv3vSSnO7H9FB/giTop8LFNFgznJy12evP7o4ENLocREoEercYkLwGefSW8DkGU3dfROpbYAWmBE46uXSwDac0dyL92QyXknKOnqHdjFtD2u3mhCFI/tzoUV15aI8LcUabfqpn0w==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
- Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
- Delivery-date: Sun, 14 Dec 2025 22:51:03 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
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.
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().
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.
~Andrew
|
