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 C04A4C47258 for ; Thu, 25 Jan 2024 12:40:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 307D18D0017; Thu, 25 Jan 2024 07:40:40 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2B6948D000C; Thu, 25 Jan 2024 07:40:40 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 132B58D0017; Thu, 25 Jan 2024 07:40:40 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id EE7828D000C for ; Thu, 25 Jan 2024 07:40:39 -0500 (EST) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id B8A37140385 for ; Thu, 25 Jan 2024 12:40:39 +0000 (UTC) X-FDA: 81717792198.21.DA50AA3 Received: from mail-ua1-f46.google.com (mail-ua1-f46.google.com [209.85.222.46]) by imf03.hostedemail.com (Postfix) with ESMTP id 77CBE20010 for ; Thu, 25 Jan 2024 12:40:36 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=Q2wt9Tq7; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf03.hostedemail.com: domain of aliceryhl@google.com designates 209.85.222.46 as permitted sender) smtp.mailfrom=aliceryhl@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706186436; 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=ZNi4MiQOUNCak4EWaCvvPwFzUIE3TXQJ5X1CGwYGEDU=; b=cgnZeXWWs6btK0NrLwXXg2D0r6PhxoydA9w90h0J449+pQaC3Rj5BRVXlX6Dh05EjK4hqM x7IVkmyaKOb74pwkaTLrvT1Xggu8ml0AN6+iSQ34v5ytPgvNMHZiWgewN7mo65gpsjsUIw 1AnxawLGxOOTZcHQZIzWeVra52J/Amc= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=Q2wt9Tq7; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf03.hostedemail.com: domain of aliceryhl@google.com designates 209.85.222.46 as permitted sender) smtp.mailfrom=aliceryhl@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706186436; a=rsa-sha256; cv=none; b=UnWfYKvDdjMa0tcdNeKlHglwnufKDt9MSVPshSt1qyAwGBD17zOO5AEwBoZb3rS3zp+3Zs oE4Yc5m4JWjT4xWOJkhHIUCYBVGn3BbiBmfpgJhjqcJESWWnj3/U7ILicR7b7ui9+Vuxw/ zL3azMbbY6AocSmUep8ArcC9YhT6uyI= Received: by mail-ua1-f46.google.com with SMTP id a1e0cc1a2514c-7cdb24b3ac3so927528241.3 for ; Thu, 25 Jan 2024 04:40:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1706186435; x=1706791235; 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=ZNi4MiQOUNCak4EWaCvvPwFzUIE3TXQJ5X1CGwYGEDU=; b=Q2wt9Tq7L69OIubUOLkhIVQIQWWSDfji0H6PyV5mDBQMUS3/GObgKZIUMefwVIlbks fjv3TBEopKIRhTavIFiauQ8RbaxqVpdmepVssl3w8G/F5GKMwD/QYpdv8wiWnSaP0rk+ nV1Krm/lu0St7zF4mEKosqAZhOFSUSRVVgZnr4PYzV35G+sBO+23kz08VozEtNxWE9fQ gVEbEKXoUR6CY3IJ3fqW5R+0WQCgE3IxRuyFnNYL0odGhvDE6PY4eB4gt9CnrdPQ8U2p Dz3Ja4h54MnFK4jP/sJM7PPJ/k7fbRR7Df+6fDToX/QvQpnN5x5gdfHXXFrdci/YvctJ 9ZBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706186435; x=1706791235; 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=ZNi4MiQOUNCak4EWaCvvPwFzUIE3TXQJ5X1CGwYGEDU=; b=a/WQrVlD+trj6WOK/vfZmiuXlnnzmtJDV3FnkIQjM+oJAUmvBtiw/bqU9kpgBA2csY dyRDTdxQgjThGDh8tkxmxvivnoeXOY+hwqdn0gxmOzQPLHOvuH47OCJ1bqVLB01LpnOS qKEWuAk3XyIrXIIYOAIKXfZyC0CNNa1ROp05RkcRZVLzTeQLlnNLUK0AK5a/6R1vx+ub 87ME5HcD3ofOWHg4wZiHvKCGVTEoh9VchS4aq701V0++tIvWFTvIok2enPRy4PcG1lgu wE8ClWAwMkzPBeY0Ot4IxcwA9ITBIgtz/5yhqfKqlSE7z3XrH2TJncSc+LEylqNcbVUi vXZw== X-Gm-Message-State: AOJu0YxThZrLOWdfLImmUWPN3nueh15c+or6ZG4SmQuQD2LQWcHwQdHH sl55Rh1xQznpaoEzO6SIM9ozhV/+nYneXlzidT2CS9tjpUOcfQIHQZ9PyZTzMY89VPnYjrRXi0/ OTz4YG2d5jUgdNMKYCAaO8Kxltufv036SaUrq X-Google-Smtp-Source: AGHT+IH1C55pZ2RrYSAI4VVBDqlGGHUKM5ynO7yFHVq9bA/uLjts2Z1tsbUOhk0J8KAoOccE1G3W7HnpyeekB5BCP+Q= X-Received: by 2002:a1f:c344:0:b0:4bd:3433:aac with SMTP id t65-20020a1fc344000000b004bd34330aacmr271077vkf.15.1706186435236; Thu, 25 Jan 2024 04:40:35 -0800 (PST) MIME-Version: 1.0 References: <20240124-alice-mm-v1-2-d1abcec83c44@google.com> <20240124234626.6435-1-kernel@valentinobst.de> In-Reply-To: <20240124234626.6435-1-kernel@valentinobst.de> From: Alice Ryhl Date: Thu, 25 Jan 2024 13:40:24 +0100 Message-ID: Subject: Re: [PATCH 2/3] rust: add typed accessors for userspace pointers To: Valentin Obst Cc: a.hindborg@samsung.com, akpm@linux-foundation.org, alex.gaynor@gmail.com, arnd@arndb.de, arve@android.com, benno.lossin@proton.me, bjorn3_gh@protonmail.com, boqun.feng@gmail.com, brauner@kernel.org, cmllamas@google.com, gary@garyguo.net, gregkh@linuxfoundation.org, joel@joelfernandes.org, keescook@chromium.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, maco@android.com, ojeda@kernel.org, rust-for-linux@vger.kernel.org, surenb@google.com, tkjos@android.com, viro@zeniv.linux.org.uk, wedsonaf@gmail.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 77CBE20010 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: mssujf4jebaok1ubor9jcz3yhm6pmom6 X-HE-Tag: 1706186436-23292 X-HE-Meta: U2FsdGVkX19+k6GqGIC0bh3NtnpMrlZru6uB8WWPyFb0sU6QemouIgcK7Ag1nk1hsaEXL/eteHuFNIlNPQXp9W3xp7k1kRJFHryiQPvulXysLcU81m2XAys/LU2m8wahCBBHL8WZQO5EgR6p5Q7IemjvAc+RuaAaAt4WhInxz/AxxsB4KbQudyA3RDcNguq1Kwb1OQXEFm/bZqjZppmCrOBOt6t4UIka4QNGWcp7lS9jA1ywVSgpUQ+c6tDACvJ571sWsssbFLjVY4TUChyi6zH98EqUwyocUr9kfP+/T6lE2gS08TK2bM3B5lo8xndoTCBRn3Q6aWoZvOqbyEcJsVbJAd2tVTJQMS6hf7ljRnT/Or9+B2jDrHT3SHyhp3cS/wLgCKjH2Km2VOjXg/Xa9cx+08di0q+4XxsMV/5v3hQV4C9kn3HbG3umfU0jcC983dk6QLFspjMDaj9LMDAAtPYfJI95H4lnK0voIXJkePrWRUdwumghNXskIUkNEOLSS6gKo/TmOD5LJHCeRYJZHFuB/LIrMS0/2FsBeOYp9S9MQhELXIWZgVFkN+1PADvIbXdkNkWcXeus51dpoC8MwP5azDFzGwoOCHSvtTa9ADiex7tXuPLAUbb7LZbrxVY5yKOU1DIv6TnuqBg8AfAC58HAs7+EM5IMUdKzfFoeZgYw9Zng0gNI9jRt3Leq+6iwW37/EmSko4e+a1XadmWPECrzmlRfj6928u5CVw58q0VrF0dcYKd+MGdN8iJS8Dm9dZ9KRGSZRtxmA4QOAafQKb/uGyzicR8olVp1m39oD2mTBmiko57Tm7s3ogDRYdF65ilk6wplMYuE9wRfXhq02n10xsqkhcYi6JIJCCMfP4eB4UYGxTlxhQrxpVbM33z54vC7LRZqadXRTV+MuiQDYn+87hJVs9krh+l3S2xdhfaBQL6qCZt2nvw0CvWRuad66xjp3iMRvaZmHsKaN6T rTceBruf z+8BuYlDF/OeebALMPajLsHLx5uRte/HfTxiEjF4+OPfRd37XGMSgsUjRlKsluK4FKKOq2ivJ2QKnFg88tms21iJXS1+KMlVURSWwVqw1AZpWiGB3RQwvDUnyXtChaarhST488XpFJtdmJK/ADG3by6JhEV+HULrJi8bDdmroiL3eGz2EmFgbC/y4Uy8auCibjwUf178NFjSIuRWeOxCErh9tgfpdpA0kzGONidEDTLPftOCVFU2nvUuIwQTNPXKzU1LPeBx+O5jXdwtn7gBA7F7YeOK2xAbx0jD+RNaFgiU6+jw= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000004, 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 Thu, Jan 25, 2024 at 12:47=E2=80=AFAM Valentin Obst wrote: > > > +/* > > nit: this would be the first comment in the kernel crate to use this > style, not sure if there is a rule about that though. Maybe still > preferable to keep it consistent. > > > + * These methods skip the `check_object_size` check that `copy_[to|fro= m]_user` > > + * normally performs. > > nit: They skip the (stronger, and also present without usercopy > hardening) `check_copy_size` wrapping that one. The only difference between check_object_size and check_copy_size is the extra check with __builtin_object_size, but that doesn't work across the C/Rust boundary, and Rust doesn't have a direct equivalent. > > In C, these checks are skipped whenever the leng= th is a > > + * compile-time constant, since when that is the case, the kernel poin= ter > > + * usually points at a local variable that is being initialized > > Question: I thought that this exemption is about dynamic size > calculations being more susceptible to bugs than hard-coded ones. Does > someone recall the original rationale for that? > > > and th= e kernel > > + * pointer is trivially non-dangling. > > As far as I know the hardened usercopy checks are not meant to catch > UAFs but rather about OOB accesses (and some info leaks). For example, > if the object is on the heap they check if the copy size exceeds the > allocation size, or, if the object is on the stack, they verify the copy > size does not leave the stack frame. Right, I can reword to say OOB instead of UAF. > > + * > > + * These helpers serve the same purpose in Rust. Whenever the length i= s known at > > + * compile-time, we call this helper to skip the check. > > + */ > > +unsigned long rust_helper_copy_from_user_unsafe_skip_check_object_size= (void *to, const void __user *from, unsigned long n) > > +{ > > + unsigned long res; > > + > > + might_fault(); > > + instrument_copy_from_user_before(to, from, n); > > + if (should_fail_usercopy()) > > + return n; > > + res =3D raw_copy_from_user(to, from, n); > > + instrument_copy_from_user_after(to, from, n, res); > > + return res; > > +} > > +EXPORT_SYMBOL_GPL(rust_helper_copy_from_user_unsafe_skip_check_object_= size); > > + > > +unsigned long rust_helper_copy_to_user_unsafe_skip_check_object_size(v= oid __user *to, const void *from, unsigned long n) > > +{ > > + might_fault(); > > + if (should_fail_usercopy()) > > + return n; > > + instrument_copy_to_user(to, from, n); > > + return raw_copy_to_user(to, from, n); > > +} > > +EXPORT_SYMBOL_GPL(rust_helper_copy_to_user_unsafe_skip_check_object_si= ze); > > Could those be wrapping `_copy_[to|from]_user` instead? Yeah maybe, see the other thread with Arnd Bergmann. Alice