From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f169.google.com (mail-qk1-f169.google.com [209.85.222.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 540641DAC81 for ; Wed, 5 Mar 2025 19:30:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.169 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741203035; cv=none; b=E6/tYjIbnf6ByfLoJUGqO7GaOcGYEzvXxazq9zFV2X+nPkvXbRY2WXOdc2i+RypA28yIieXof1KsVTHhUp3d4/wdmrQP/6Js1pPeXhcBzCbHmk4dkz78LGz2ONx/6blZeTiiTeIEdAtEREvibUkZ9M4VH6jQthiXNbBte5jZ60A= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741203035; c=relaxed/simple; bh=t6SiDVwaTHvhAlwjcDp2TYwOA5pPtU4A7kw092Af/vg=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=u4KZZJlOT6/hyJQ6pRZd+Roeg+XvoSQAXSgf0NssKMzhWUBqbIx7kKBkVj9MesH6XdcnyIleDK7bGf/g2vodJ9T1Wq3R0lNddSuLsjRVwqUwO5mVxGswCW0vPFXvypS4R5P0gh4MxNjulpaGEDPum9gwVqWjI92slG6774FcmEU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=rowland.harvard.edu; spf=fail smtp.mailfrom=g.harvard.edu; dkim=pass (2048-bit key) header.d=rowland.harvard.edu header.i=@rowland.harvard.edu header.b=K1Hpl/0L; arc=none smtp.client-ip=209.85.222.169 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=rowland.harvard.edu Authentication-Results: smtp.subspace.kernel.org; spf=fail smtp.mailfrom=g.harvard.edu Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=rowland.harvard.edu header.i=@rowland.harvard.edu header.b="K1Hpl/0L" Received: by mail-qk1-f169.google.com with SMTP id af79cd13be357-7c08b14baa9so612006485a.3 for ; Wed, 05 Mar 2025 11:30:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rowland.harvard.edu; s=google; t=1741203032; x=1741807832; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=oId15+YDneGVvUrzPX64hfAInMf60MXmTWB86DACpPE=; b=K1Hpl/0Lf2e0SMJsD78cI6VUZa8YeaVGGCzQxRGADes3BSjSQp5MCTIT7pduSbLp3Z rqPQiRCGHImqUOmJtdm6EbBZOu9getLYxNi7Tax+opRvbAJr3Gneh+LVQZqRREGf20zW 4turkQEZZhp/Px7w34mnLx7bNjJaa+5MyqFC2cVPS3kriaOEqHsEDYVNTPRFK2Q6wC3s A6kKge3iwyrZOHtYD+7RTPNxTjw4BP+SspGU+LqGiWeuxEyrJFoYqO+oXe9pHf+MQ7GV Yht1CVgXQHbbrrTwMgiuk6NLPQaQrlZt9O55ePQz0DnuPERl8xrcDL97DeM/vu0OEdA7 J8KQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741203032; x=1741807832; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=oId15+YDneGVvUrzPX64hfAInMf60MXmTWB86DACpPE=; b=mgMLddMtEBVTQQQOiemmvo7BzMsUtEfdWB3bhaIbE0R2kP9nbl556GZ83zpak6LmOt YDQgHToI4fkr2YVMvNVhv0/O+3N1CHxNYLFSWPQR6abnJ75KLBnGKRYA1u+zDINRkaKF OtdQozGrK8IZUoZw9efCQ9izuNd7Tr2X7MPmsMXudeOsL03AtVNFAJ7CUQqsVCESIbQW kJoMfzzk07MNG+5Fzu9EpU8zttrYcFR10fXcnLH+CB6nHdJyuK2aTqmH/f/l4GGEwvyj KYtcNLJWNb6Bh8LfTOQyGrQrsWBf1ZBqwMSXIQxBkseBigGazT3sLNKBWjZdWpD+ZNYt 8QGg== X-Forwarded-Encrypted: i=1; AJvYcCUxgXHP40Z83lgVZJBUN+CePk99TDh80vjQbglE5YfsVkHkh1Doac6dDVuEj8um5ZDKCumNmWCPXWl+iBPhxQ==@vger.kernel.org X-Gm-Message-State: AOJu0YzaS+u0PVQOgozDb2HixjNnhZIF+vhgTxMKv3jwx1mFrpLFpozz hlv7r4OWExU4ruBN+BffrAthmuW4Pn3y5HrDBmeZSzqtwq7LcLPm0+Vs4V0Y0Q== X-Gm-Gg: ASbGnct0T9rDYCdnEMDVLqIs4xjBZJc0hqKawKdYITjKz6i8K3qGouuQX80zfNdLFdY m5lAo27klQdBGsAgU2GLlA7MHAHC143c0PFtmbTzeD95734nfot/lQ1X5RWHi0HxkLqsCvqjcDW ld80zt3FzvdmBKsRuPGe4T6HGcocabx086glgyKeyxST9IFceCeukKSl3u0wcQUgcH+GcUN2B/t JKXgEhV+PUg2b1g9F5NEYeaSbRiCuWydxDIBAO7z7FQpINymKvix8Yx8nDd7yK4BPd4Sk2EBHpB kF9MiuRoqrGMQCRPa9LsdK4YUDviWlqNpzMjPhGUDHdy1Saeo6QneK6T0KV4kW1qVxkZMMp+YOA CqeFsIuoQBad9eUKdFzmKI3CXdcoztyWVjDMCTw== X-Google-Smtp-Source: AGHT+IEdHIEYyOFA6iBD4IRAvEEK44U33sXsSKu1qSukoScCCId/HavsdZVIN+N6mZ49Avbu1kb/wA== X-Received: by 2002:a05:620a:84c4:b0:7c0:a0fd:7b2c with SMTP id af79cd13be357-7c3d8e55666mr759133185a.22.1741203032165; Wed, 05 Mar 2025 11:30:32 -0800 (PST) Received: from rowland.harvard.edu (nat-65-112-8-24.harvard-secure.wrls.harvard.edu. [65.112.8.24]) by smtp.gmail.com with ESMTPSA id af79cd13be357-7c3d30234c7sm214999985a.34.2025.03.05.11.30.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 05 Mar 2025 11:30:31 -0800 (PST) Date: Wed, 5 Mar 2025 14:30:28 -0500 From: Alan Stern To: Andreas Hindborg Cc: Ralf Jung , Alice Ryhl , Boqun Feng , comex , Daniel Almeida , Benno Lossin , Abdiel Janulgue , dakr@kernel.org, robin.murphy@arm.com, rust-for-linux@vger.kernel.org, Miguel Ojeda , Alex Gaynor , Gary Guo , =?iso-8859-1?Q?Bj=F6rn?= Roy Baron , Trevor Gross , Valentin Obst , linux-kernel@vger.kernel.org, Christoph Hellwig , Marek Szyprowski , airlied@redhat.com, iommu@lists.linux.dev, lkmm@lists.linux.dev Subject: Re: Allow data races on some read/write operations Message-ID: <471eec19-1abb-43f1-aec0-d0db56f6ca9e@rowland.harvard.edu> References: <87mse2hrd8.fsf@kernel.org> <88456D33-C5CA-4F4F-990E-8C5F2AF7EAF9@gmail.com> <25e7e425-ae72-4370-ae95-958882a07df9@ralfj.de> <18cmxblLU2QAa4YP25RWCKEnxuonOwWXavYmSsS4C5D40o8RaCkIXo0UDZ2SPnksk5nWYB29Y4zHkjQeOgd4ng==@protonmail.internalid> <3aabca39-4658-454a-b0e3-e946e72977e1@ralfj.de> <87eczb71xs.fsf@kernel.org> Precedence: bulk X-Mailing-List: rust-for-linux@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87eczb71xs.fsf@kernel.org> On Wed, Mar 05, 2025 at 07:43:59PM +0100, Andreas Hindborg wrote: > "Ralf Jung" writes: > > > Hi, > > > > On 05.03.25 14:23, Alice Ryhl wrote: > >> On Wed, Mar 5, 2025 at 2:10 PM Ralf Jung wrote: > >>> > >>> Hi, > >>> > >>> On 05.03.25 04:24, Boqun Feng wrote: > >>>> On Tue, Mar 04, 2025 at 12:18:28PM -0800, comex wrote: > >>>>> > >>>>>> On Mar 4, 2025, at 11:03 AM, Ralf Jung wrote: > >>>>> However, these optimizations should rarely trigger misbehavior in > >>>>> practice, so I wouldn’t be surprised if Linux had some code that > >>>>> expected memcpy to act volatile… > >>>>> > >>>> > >>>> Also in this particular case we are discussing [1], it's a memcpy (from > >>>> or to) a DMA buffer, which means the device can also read or write the > >>>> memory, therefore the content of the memory may be altered outside the > >>>> program (the kernel), so we cannot use copy_nonoverlapping() I believe. > >>>> > >>>> [1]: https://lore.kernel.org/rust-for-linux/87bjuil15w.fsf@kernel.org/ > >>> > >>> Is there actually a potential for races (with reads by hardware, not other > >>> threads) on the memcpy'd memory? Or is this the pattern where you copy some data > >>> somewhere and then set a flag in an MMIO register to indicate that the data is > >>> ready and the device can start reading it? In the latter case, the actual data > >>> copy does not race with anything, so it can be a regular non-atomic non-volatile > >>> memcpy. The flag write *should* be a release write, and release volatile writes > >>> do not exist, so that is a problem, but it's a separate problem from volatile > >>> memcpy. One can use a release fence followed by a relaxed write instead. > >>> Volatile writes do not currently act like relaxed writes, but you need that > >>> anyway for WRITE_ONCE to make sense so it seems fine to rely on that here as well. > >>> > >>> Rust should have atomic volatile accesses, and various ideas have been proposed > >>> over the years, but sadly nobody has shown up to try and push this through. > >>> > >>> If the memcpy itself can indeed race, you need an atomic volatile memcpy -- > >>> which neither C nor Rust have, though there are proposals for atomic memcpy (and > >>> arguably, there should be a way to interact with a device using non-volatile > >>> atomics... but anyway in the LKMM, atomics are modeled with volatile, so things > >>> are even more entangled than usual ;). > >> > >> For some kinds of hardware, we might not want to trust the hardware. > >> I.e., there is no race under normal operation, but the hardware could > >> have a bug or be malicious and we might not want that to result in UB. > >> This is pretty similar to syscalls that take a pointer into userspace > >> memory and read it - userspace shouldn't modify that memory during the > >> syscall, but it can and if it does, that should be well-defined. > >> (Though in the case of userspace, the copy happens in asm since it > >> also needs to deal with virtual memory and so on.) > > > > Wow you are really doing your best to combine all the hard problems at the same > > time. ;) > > Sharing memory with untrusted parties is another tricky issue, and even leaving > > aside all the theoretical trouble, practically speaking you'll want to > > exclusively use atomic accesses to interact with such memory. So doing this > > properly requires atomic memcpy. I don't know what that is blocked on, but it is > > good to know that it would help the kernel. > > I am sort of baffled by this, since the C kernel has no such thing and > has worked fine for a few years. Is it a property of Rust that causes us > to need atomic memcpy, or is what the C kernel is doing potentially dangerous? I agree; this is a strange discussion. What is it that people want to protect against? If the issue is undefined behavior caused by a second party modifying the source of a memcpy() while the copy is in progress -- well, there's no way to protect against that. You just have to make sure either that it cannot happen or else that you can cope with potentially torn values in the copy's destination. Is the issue a matter of informing verifiers or sanitizers that a data race during a memcpy() shouldn't count as undefined behavior? Surely the way to do this depends on the verifier/sanitizer in question. As far as I know, there is no version of memcpy() whose arguments are declared to be pointers to atomics. (And if such a thing did exist, it would be part of C++, not of C.) Alan Stern