From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 99FF2C48297 for ; Mon, 12 Feb 2024 09:30:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 182A36B0078; Mon, 12 Feb 2024 04:30:40 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 10C2D6B007E; Mon, 12 Feb 2024 04:30:40 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EC7B96B0080; Mon, 12 Feb 2024 04:30:39 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id D7B2B6B0078 for ; Mon, 12 Feb 2024 04:30:39 -0500 (EST) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 515231C0B41 for ; Mon, 12 Feb 2024 09:30:39 +0000 (UTC) X-FDA: 81782631798.05.B3D78BD Received: from mail-vk1-f170.google.com (mail-vk1-f170.google.com [209.85.221.170]) by imf27.hostedemail.com (Postfix) with ESMTP id 8A2404000E for ; Mon, 12 Feb 2024 09:30:36 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=JG1lbQfq; spf=pass (imf27.hostedemail.com: domain of aliceryhl@google.com designates 209.85.221.170 as permitted sender) smtp.mailfrom=aliceryhl@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1707730236; a=rsa-sha256; cv=none; b=GOsCKnAhP7gFKrd6mcUbYWUs6NfFSCYdsHgUFINJ9iVTnrDACgKWF4qYVDw5raNJhgCcfC XUf4o6yPQ58Ps2EdCP9Y8o7pzl0EZW9fBj1twBuVdVDHi5FS4WMb8k1nyYK76u6vwGfKGY eqbH8kPG1E5g+ht1Wj1BmpmpO/YaX84= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=JG1lbQfq; spf=pass (imf27.hostedemail.com: domain of aliceryhl@google.com designates 209.85.221.170 as permitted sender) smtp.mailfrom=aliceryhl@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1707730236; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=aVJXg04dDq3HdGdQbSODm4X+NrUwFF5O5k1QDLQ/4FQ=; b=atMRHrfQjfoePuBcpiEgUxZ2FZ6enHEysSDiTYow255GdIzJ3g1AgSoPU6ol7EOTFam/5v b3LglXEzk+99bfNI4Q5hFlcg/zDj2NI6lsOvkZkD5nWB9Yrx+3RHHCLKlyNjmTuOhtyVPk CnflAwe6JJwHBvQvoIZMvaDdXueCmFE= Received: by mail-vk1-f170.google.com with SMTP id 71dfb90a1353d-4c0245cba99so505363e0c.0 for ; Mon, 12 Feb 2024 01:30:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1707730235; x=1708335035; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=aVJXg04dDq3HdGdQbSODm4X+NrUwFF5O5k1QDLQ/4FQ=; b=JG1lbQfqdk9ZbE1o/9XIEYSv+ixuiU+gLAXHpQAjWkDHNmlDXwn0Cn9h6NDR+NlvWY Ou8s5dTxGoKTxHdzYlG3luoXaScm+k9yGPbca6VI1cDqYYMS6KR1cpZs7r9re74jMUVp XtZcH4Jccr7KnRAgJLBz3KcuUlodZ4URlRD8Z/8Tn60n3bW/rkadRB7T+IVk9lny5sON bgiTKV6bAXANK0C/gnttWluQDsu1lNf5teXvAsaimCsq3zJo1dWoRin1OUy3FInXph29 WxRfxZhJTsmmAi+W8ZTU/SMB0onI1GKRO2Z4kiKQFPkMLqHmSA6FbUb6G4FFFn/6fPQm WD2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707730235; x=1708335035; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=aVJXg04dDq3HdGdQbSODm4X+NrUwFF5O5k1QDLQ/4FQ=; b=eAX2N59v78caO0BblQg9648h+9IzjU4/b0vUi2nV+5GLwQByC/PlZtmH5aL1ZIKIMY sSuuQp1HTXrp7Jg7Kde5zMBlH/SfcZVxcdcZO/roWNpnR2CNipYQgbugox0ErYpUd39c OAG4kwIo24c2SdKAa7MWR5YqSrZcbnIxwpbm3U/h0HIFi9yUnoHnyEbEqPUBhrb2pj/4 VhCirHHo/j2tFgKc6aKEXJ94PiwXJzH0g+WWD5+oo1OCkeRQLrQnm1NojfUnNey71RHo EHxFoFA9S2+8PAA6LNTTc5PH5C+TWolaYOLabsxxRBUFPK8EYx+PYDshgdK0de4IUmy2 uJGw== X-Forwarded-Encrypted: i=1; AJvYcCWRhrFH5JfvEVyM82qpfSAj5t/oM9Wl9ktqJdQlJN2Y3a5WXHVyvP7NGuFT001X7nKSUBKoJV4YStjxN1yDIuvI9M4= X-Gm-Message-State: AOJu0YzW6j4J+ywNi3XGoSC/SM8N+dXvMp2AMYzy2Kw1qrB/8wFFWvBt AjvJPXiFKudFgjWuPWoI0AdrRtN97q1hYdQAW+hv61Ir+mnd1j4ZMMH6RtB5xPuPyd/M9UkvEv6 rCYOCeIiwpgYRAhq4VX+9ma/9qnotDSSXphbR X-Google-Smtp-Source: AGHT+IHjV73mgJjltlbGotOak1PzxKLwy9aSO2nJ7D7f32xXmGKQCv9rUvPaFsRmWhNsUhe7k0oa8HywUsDXuUQEtS8= X-Received: by 2002:a1f:e403:0:b0:4c0:3552:bd07 with SMTP id b3-20020a1fe403000000b004c03552bd07mr2504043vkh.9.1707730235423; Mon, 12 Feb 2024 01:30:35 -0800 (PST) MIME-Version: 1.0 References: <20240124-alice-mm-v1-0-d1abcec83c44@google.com> <20240124-alice-mm-v1-1-d1abcec83c44@google.com> <405e8b56cd0c48d0ba640e8d9c60179e@AcuMS.aculab.com> In-Reply-To: <405e8b56cd0c48d0ba640e8d9c60179e@AcuMS.aculab.com> From: Alice Ryhl Date: Mon, 12 Feb 2024 10:30:24 +0100 Message-ID: Subject: Re: [PATCH 1/3] rust: add userspace pointers To: David Laight Cc: Trevor Gross , Miguel Ojeda , Alex Gaynor , Wedson Almeida Filho , Boqun Feng , Gary Guo , =?UTF-8?Q?Bj=C3=B6rn_Roy_Baron?= , Benno Lossin , Andreas Hindborg , Kees Cook , Al Viro , Andrew Morton , Greg Kroah-Hartman , =?UTF-8?B?QXJ2ZSBIasO4bm5ldsOlZw==?= , Todd Kjos , Martijn Coenen , Joel Fernandes , Carlos Llamas , Suren Baghdasaryan , Arnd Bergmann , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , "rust-for-linux@vger.kernel.org" , Christian Brauner Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 8A2404000E X-Stat-Signature: w4x78nc8r7x97unjsw1rck1wwg1qdr7e X-Rspam-User: X-HE-Tag: 1707730236-502834 X-HE-Meta: U2FsdGVkX19nnP2SuwwhviWa55ZwZbd9CsK5MHUoSlNCv46YHqaUPC+fSqlO968W+p9UxHVcKcqradqCQL7OwmKAeQwpzqSX3JCybuFRWNIReN2ByS+ZgrGCFouoJ4Xdvb4arrtf2EqFxhmZRvyPerb0ih/TT3AWaPmdeuLAIXIMweDLXNrNFf7y22IWULFYhgl5YpN/Qs/9JFxoXJvO4JMSlSoWr/BTs42pMkYYyWADR6hCQ8G4Bev7RxB+vh+bO2J0ladyyqVtO1L8aHCTdYWBjbXWiGOGJnb63ClmX9hJVRHnwyFRO68+qkv9BgGJkpzjEY2qfbB5gkI6fZelS72Bb8sY9nltDMe/vD9Ol3SQIFxmymRqQLs6ZYrJ1R2658HwUHlDGCdm9L+ag42g7Ily2MoKs+fEIMjLzVzlNamRkgOo2BgKkrn8E413Dl0PAm64CZHSSbISp6sIA9JuylWp+LmREpGRd3XMuj5A7zZIiUKoYnN5tBW52NmbDfCasK3GwHN8xsYIzO7lS2Sc0/3FAkS55p8P60TSJjq2DtS8FLmaEn2+Cs8XlrEcrwuZ+zR1020gAnUPDEcLpIUchIoSxHTkT8sONPpYo9xGCAOKHO4Y5vr5Ea16l8iMxBpPdskol+MaawalmxC7QOlOBux9hbc0LBIC0xpdiwRwpWHu3wNrjBqhOoOM6xGnoSguNp5XodttDuIyqTieHdLTHWXB8N0VBPhLl4qFP8XjuP8MEy0+uwO7eBeWux7RBIhVF3tGw0JjDy9HNuof2TfhQXWHHimTtOA0d0eSkucQLKFa52SM5PrYQ6QxYDAveGXYs679Wwv7Hyq+i9vvu24H0+QycWfncMnq8kYfo+0BOQM5eRAT2aS/Aqx5pZD5UOIUwlP4VGddugK3KqH91vfRPc8xlif8yxTCr8sDpAxr3ZUfVnGsLqyPk2uKR7/Jf13kb9Q82KYvKANHGHdRH2y oSwYUZRy iZ6n3k0gWNkTjQurKwJivDfc3HKwaZ+X5YWTbvBe0SF1eMUxjQ1IgjoyGhS/P1oMZRVcIxQs0OzSOHyr6bCU7NVXYgGuueV+p8BVXpgfd3emwIEpc+PdOu4Snao1UTG0mnCwdT3wrOTVTnf4W4t1N4xbtKa8hwmxkLH/Kan8XIWM2Rwzbh7yTccaSRpXQrljJw2FgF6sXbPDMGV48DoOykdvAkIh9/LTdmblYjnNuYaMiuryFBeROgUJcRE2p027WGNpFFTXHKN4m00HGVf2Qtzr1++wHt473PSQBQgmZSefB9bb59L4Oe2AtQu3YEulzEP+MQOxOHODzUtrhqwSc6wZMXneWWpXJhHz+HwwbFF/Sz72iE0MbQuBSLQPpH7qa+if7pq7NpMkBDWuvbgh46BTn9H0yJaUzT1ht5lKuNHra8SDQ8S6j+1OMxvUM0tXdajCYkqhdYMInltIpTVHNSeB/7gLXmQakOmMF X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Sat, Feb 10, 2024 at 3:15=E2=80=AFPM David Laight wrote: > > ... > > > Maybe something like > > > > > > Every time a memory location is read, the reader's position is ad= vanced by > > > the read length and the next read will start from there. This hel= ps prevent > > > accidentally reading the same location twice and causing a TOCTOU= bug. > > WTF TOCTOU? I'm guessing it is reading things twice and getting > different answers. Yes. In v2 of this patchset [1], I expanded TOCTOU to "time-of-check to time-of-use" at the first use to reduce this confusion. > That really doesn't match how copying from userspace is used is many plac= es. > Sometimes you really do want to be using offsets and lengths. > For instance the user buffer might contain offsets of items further > down the buffer. For this use-case, you can call UserSlice::new multiple times, or use clone_reader. This use-case does appear sometimes in Rust Binder and is supported, but I didn't find it to be the most common use-case. > There is also the code (eg ioctl) that does a read-modify-write > on a buffer. The read-modify-write use-case is quite common in Rust Binder and is supported by the API provided by this patchset. When you call reader_writer, you get a separate reader and writer. Then, you first use the reader to read the data. Then you modify it. Then you use the writer to write it back. > > > + /// Reads the entirety of the user slice. > > > + /// > > > + /// Returns `EFAULT` if the address does not currently point to > > > + /// mapped, readable memory. > > > + pub fn read_all(self) -> Result> { > > > + self.reader().read_all() > > > + } > > > > If I understand it correctly, the function will return `EFAULT` if _any= _ > > address in the interval `[self.0, self.0 + self.1)` does not point to > > mapped, readable memory. Maybe the docs could be more explicit. > > That isn't (and can't be) how it works. > access_ok() checks that the buffer isn't in kernel space. > The copy is then done until it actually faults on an invalid address. > In that case the destination buffer has been updated to the point > of failure. > > You can't do a check before the copy because another thread can > change the mapping (it would also be horribly expensive). This was reworded in v2 [1]: /// Fails with `EFAULT` if the read encounters a page fault. But ultimately, the real condition here is just that it returns EFAULT if copy_from_user fails. I'm happy to reword further. Alice [1]: https://lore.kernel.org/all/20240208-alice-mm-v2-1-d821250204a6@google= .com/