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 67D2EC4345F for ; Mon, 15 Apr 2024 21:53:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C2CB96B0088; Mon, 15 Apr 2024 17:53:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BDD386B0089; Mon, 15 Apr 2024 17:53:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A7DAB6B008A; Mon, 15 Apr 2024 17:53:28 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 897EE6B0088 for ; Mon, 15 Apr 2024 17:53:28 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 109338081C for ; Mon, 15 Apr 2024 21:53:28 +0000 (UTC) X-FDA: 82013118096.01.F4C2925 Received: from mail-qt1-f181.google.com (mail-qt1-f181.google.com [209.85.160.181]) by imf26.hostedemail.com (Postfix) with ESMTP id 0E96614000F for ; Mon, 15 Apr 2024 21:53:25 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=fJKuSKbj; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf26.hostedemail.com: domain of boqun.feng@gmail.com designates 209.85.160.181 as permitted sender) smtp.mailfrom=boqun.feng@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1713218006; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=X4QjxBzsTXB7diBcl5dTgdSW8x93qRsLQtekUiqvII8=; b=MDRdXfsu+0e0naL53QJHzIO7GupKJJ6Sm+VqGLHFNctZkdkRSv9LZnJKILd8csxghOVktd I9fd9n443U+9Qgv1YZkn3q11/y4jSb6LXQVzzm62dRgKs/z/ThIsNeUdThsE441oDC9OAg eKs5XSqTGoqbzswMH5IAqXvlU4YX1Ks= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=fJKuSKbj; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf26.hostedemail.com: domain of boqun.feng@gmail.com designates 209.85.160.181 as permitted sender) smtp.mailfrom=boqun.feng@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1713218006; a=rsa-sha256; cv=none; b=gDXfKxNc4LDAuhy1EJOd2BD7sTan6kshy5eCegGZC2i242dVzptWCIUDSaZnubsOqPiotf I4rNxyqGKBkki0rKD010Jh2ir6ExwRRpS93Yk2I/BkoIDWze3WMoMe9hpONQ3rTM0IpbI1 sKFb0Ad8bRS1NEPHOs7V1pFvWRxwtto= Received: by mail-qt1-f181.google.com with SMTP id d75a77b69052e-436f1a770bdso13707201cf.0 for ; Mon, 15 Apr 2024 14:53:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1713218005; x=1713822805; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:feedback-id:from:to:cc:subject:date :message-id:reply-to; bh=X4QjxBzsTXB7diBcl5dTgdSW8x93qRsLQtekUiqvII8=; b=fJKuSKbjjAZH3ocLE1mxum+CRV6Q42tkrkY77VX4VhjwuJeZVdaIxA71qnzEzlspSW 8hTMoRJQBoJUcFe5a7R8XCTwXWo+CkKCya0jUzA/qkhcbj2aBsFqbW1EXjJVZ0l+VwyA w7Z4GIsaeL0IsSu/gVWy7GRG6YKnZ2QVGVe1N1MgzJY+rIKrcB6nNKs6ET4YENnp6yP5 Wxd24ghPuQJoaOuIPzRvHVU29ENhhadl+z9u8ZB8ZIwhSdwqJPzNfdOQ8DBEDBRKvAAp 3ybKexcN65q7NbQJhlEH1V5McdDJeXp4GBP0VKkigJ0iip6ER41Arq9uv+3xa5PQyJoZ s1ag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713218005; x=1713822805; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:feedback-id:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=X4QjxBzsTXB7diBcl5dTgdSW8x93qRsLQtekUiqvII8=; b=vLC/1ZZ/tJVOGkbGC5xtsQxZWqnEnXPdgyqsCzuQqYM6HZgaEIv5AZvhki/IhQ0llF SP1GGxZRJFk/XAuuVCq6DFaAVXtUDQLvum6wJpRbxPb6j09vEH9NU0fnf+htIMcl4Nus 9MsJe5P23Gs14ZboWLWXAOGSTsMmvfTcWzKO0AJAbDDZi/bjrPSkZvHL/k72bH0jxZyT ilzz/BawisYQaOyl0gqMSD6sYDCEn8qwC0qoQzhTzSF9EiCcCDxynHVuVbS6e8/54NRm T1MJjLbOtkw8h9E1yh9dMlgVGF+S62huu6FFsiqJbK7/UVc89Z2/xAq321ZaN3OTv9SP ElMQ== X-Forwarded-Encrypted: i=1; AJvYcCWNOoy5zyGKr0qrryRwhHnx2i4YAiNKdbftitmGeQpbvdyb6VkcbJ8eKV/BvOVZgwhgKsHRO+w/VDZN7lAIGZqY/Zo= X-Gm-Message-State: AOJu0Yxtn5jLnD3ieEapcDjwKKLUCOq84fTzjQGFVCn3xEDUf4pgRQhS DAxGz1S3465bWk3d8ZGQwkLus8pZ1AIv+mtVHQ8/fauSQxcTnah9 X-Google-Smtp-Source: AGHT+IGfTlcT01C0SngR63rLuC0OJbsEwwsCHS3hFr45/xbB+8hfJ+Wejt8gAURALG3QrWoVnNJJ3w== X-Received: by 2002:ac8:5741:0:b0:434:e7d6:b51b with SMTP id 1-20020ac85741000000b00434e7d6b51bmr1616157qtx.31.1713218004948; Mon, 15 Apr 2024 14:53:24 -0700 (PDT) Received: from fauth1-smtp.messagingengine.com (fauth1-smtp.messagingengine.com. [103.168.172.200]) by smtp.gmail.com with ESMTPSA id fu28-20020a05622a5d9c00b00436510ddc5esm6517347qtb.34.2024.04.15.14.53.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 15 Apr 2024 14:53:24 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.48]) by mailfauth.nyi.internal (Postfix) with ESMTP id 8E4381200066; Mon, 15 Apr 2024 17:53:23 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Mon, 15 Apr 2024 17:53:23 -0400 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrudejfedgtddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvfevuffkfhggtggujgesthdtredttddtvdenucfhrhhomhepuehoqhhu nhcuhfgvnhhguceosghoqhhunhdrfhgvnhhgsehgmhgrihhlrdgtohhmqeenucggtffrrg htthgvrhhnpeehudfgudffffetuedtvdehueevledvhfelleeivedtgeeuhfegueeviedu ffeivdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe gsohhquhhnodhmvghsmhhtphgruhhthhhpvghrshhonhgrlhhithihqdeiledvgeehtdei gedqudejjeekheehhedvqdgsohhquhhnrdhfvghngheppehgmhgrihhlrdgtohhmsehfih igmhgvrdhnrghmvg X-ME-Proxy: Feedback-ID: iad51458e:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 15 Apr 2024 17:53:22 -0400 (EDT) Date: Mon, 15 Apr 2024 14:53:07 -0700 From: Boqun Feng To: Alice Ryhl Cc: Miguel Ojeda , Matthew Wilcox , Al Viro , Andrew Morton , Kees Cook , Alex Gaynor , Wedson Almeida Filho , Gary Guo , =?iso-8859-1?Q?Bj=F6rn?= Roy Baron , Benno Lossin , Andreas Hindborg , Greg Kroah-Hartman , Arve =?iso-8859-1?B?SGr4bm5lduVn?= , 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 Subject: Re: [PATCH v5 1/4] rust: uaccess: add userspace pointers Message-ID: References: <20240415-alice-mm-v5-0-6f55e4d8ef51@google.com> <20240415-alice-mm-v5-1-6f55e4d8ef51@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240415-alice-mm-v5-1-6f55e4d8ef51@google.com> X-Rspamd-Queue-Id: 0E96614000F X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: 7eidos7wefksx48sioi3q57u7csucpqk X-HE-Tag: 1713218005-954078 X-HE-Meta: U2FsdGVkX18e8ykjPfO5tnlkW5pZ2rQMrD48AMZAJd6/X0SZY0XTK42XQF3DiHB0F2Em27EetN16fvTFCKIKgdStCy1J7SUJGFdHriZDCCQG8dJZ7hVIL3mHN7aYX/04neMJN4gxPufkKkHwqIJlBlRxuVB7Hc//Lt4TRgWBPOK2w7R+0Zp9C0yQF+vcwl8/DBdNsvJpzaSx+q+FUZ9zEihMB6FeMXzD8uzU+ffUuBPibFJ5R2y8ers/P9mUtELuk9PaIJmV2yTrwvjDahKFqdmjIDS1WV5AgrpKPtRjc3/I5wgNUJBxDSA8U+62n2/GAbzSM6gDWyKqlEBiIJ0zjheX0F+28x6s3o7Tq6gUwIJJj7NDANlUv5DeSCneXMxLifEGu0GKq1cfeSxCYePz5WvnhgUmlRx9YK/6yOvG1cT0uP6bYqFutrlV9Hl9OdOvhda4vat9XvMIbLDPv8bVTzz1qPeLebOVSOjSRYms4/a8KpbW1EJNpLpl4LJxZ51PiNiCYookc1HJAEJ8i8VZ6juFK+9nV/J1QtfqU0pI9kzT61ORCTudkBay3BWQonpkeUHlqVysGTqMu8FUJq8/OMAY99881/2JEPmVVVvEU1BrwEgOCmifFTpm3mEmwIoDFgDdL6EUBdFNiCp5TXa87qteg6966d+PmlOl+Tud0w8pNEyaqIowWqoOMlM1c96hPmVL4/j6tYWhaIdCnieaSYCGhazTF6Tl/vKXWbxXS1ELAD7tDzq7W5HqVoAl9Li5YhPF7T2+t8jSWx84KcPAnd1mCTtx47PqupbpeU4JDh0QeBWsc6Kxxq2WHO/JpXy9wPUfD6qLYrustjac7MQ8ec8dtZNVzpMTZdTn+xN6mAVgDfwdCMgSIMwsN9rPwBViCEoWqCt9fsYDsnUJMvflzVJ7DTUjdb+GrVD4vImF/QsCP6dOT7XGHtgd4mRKxLUEeFgoK0Ya2tcY7M0O/9h 3VOPW/GX XWNFctmG59Yy4tPl3pmZ4Vgc+efhwcUj42qHKJ58n91Bh1LDyA9C16hVckirk5Wy++h/DmxB4E8EtN8fl/iGFD6SK7hD6P7fj9FpSZdRBzu3bynmgP6+b+W39Qf1yV2ns2TZQ1fkCqWzq3B8jw7IZJ6ZnbCGc1VMCG5/musKb5J70fsRm2hmTJXTUcw== 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 Mon, Apr 15, 2024 at 07:13:53AM +0000, Alice Ryhl wrote: > From: Wedson Almeida Filho > > A pointer to an area in userspace memory, which can be either read-only > or read-write. > > All methods on this struct are safe: attempting to read or write on bad > addresses (either out of the bound of the slice or unmapped addresses) > will return `EFAULT`. Concurrent access, *including data races to/from > userspace memory*, is permitted, because fundamentally another userspace > thread/process could always be modifying memory at the same time (in the > same way that userspace Rust's `std::io` permits data races with the > contents of files on disk). In the presence of a race, the exact byte > values read/written are unspecified but the operation is well-defined. > Kernelspace code should validate its copy of data after completing a > read, and not expect that multiple reads of the same address will return > the same value. > > These APIs are designed to make it difficult to accidentally write > TOCTOU bugs. Every time you read from a memory location, the pointer is > advanced by the length so that you cannot use that reader to read the > same memory location twice. Preventing double-fetches avoids TOCTOU > bugs. This is accomplished by taking `self` by value to prevent > obtaining multiple readers on a given `UserSlicePtr`, and the readers > only permitting forward reads. If double-fetching a memory location is > necessary for some reason, then that is done by creating multiple > readers to the same memory location. > > Constructing a `UserSlicePtr` performs no checks on the provided > address and length, it can safely be constructed inside a kernel thread > with no current userspace process. Reads and writes wrap the kernel APIs > `copy_from_user` and `copy_to_user`, which check the memory map of the > current process and enforce that the address range is within the user > range (no additional calls to `access_ok` are needed). > > This code is based on something that was originally written by Wedson on > the old rust branch. It was modified by Alice by removing the > `IoBufferReader` and `IoBufferWriter` traits, and various other changes. > > Signed-off-by: Wedson Almeida Filho > Co-developed-by: Alice Ryhl > Signed-off-by: Alice Ryhl Thanks! Reviewed-by: Boqun Feng Two small nits below.. > --- > rust/helpers.c | 14 +++ > rust/kernel/lib.rs | 1 + > rust/kernel/uaccess.rs | 304 +++++++++++++++++++++++++++++++++++++++++++++++++ > 3 files changed, 319 insertions(+) > [...] > + /// Reads raw data from the user slice into a kernel buffer. > + /// > + /// Fails with `EFAULT` if the read happens on a bad address. ... we probably want to mention that `out` may get modified even in failure cases. > + pub fn read_slice(&mut self, out: &mut [u8]) -> Result { > + // SAFETY: The types are compatible and `read_raw` doesn't write uninitialized bytes to > + // `out`. > + let out = unsafe { &mut *(out as *mut [u8] as *mut [MaybeUninit]) }; > + self.read_raw(out) > + } > + [...] > + > +impl UserSliceWriter { [...] > + > + /// Writes raw data to this user pointer from a kernel buffer. > + /// > + /// Fails with `EFAULT` if the write happens on a bad address. Same here, probably mention that: the userspace memory may be modified even in failure cases. Anyway, they are not correctness critical, so we can do these in later patches. Regards, Boqun > + pub fn write_slice(&mut self, data: &[u8]) -> Result { > + let len = data.len(); > + let data_ptr = data.as_ptr().cast::(); > + if len > self.length { > + return Err(EFAULT); > + } > + let Ok(len_ulong) = c_ulong::try_from(len) else { > + return Err(EFAULT); > + }; > + // SAFETY: `data_ptr` points into an immutable slice of length `len_ulong`, so we may read > + // that many bytes from it. > + let res = unsafe { bindings::copy_to_user(self.ptr, data_ptr, len_ulong) }; > + if res != 0 { > + return Err(EFAULT); > + } > + // Userspace pointers are not directly dereferencable by the kernel, so > + // we cannot use `add`, which has C-style rules for defined behavior. > + self.ptr = self.ptr.wrapping_byte_add(len); > + self.length -= len; > + Ok(()) > + } > +} > > -- > 2.44.0.683.g7961c838ac-goog > >