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 89E5CC4828F for ; Fri, 9 Feb 2024 10:40:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EA9336B0078; Fri, 9 Feb 2024 05:40:38 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E32426B007E; Fri, 9 Feb 2024 05:40:38 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CD37E6B0080; Fri, 9 Feb 2024 05:40:38 -0500 (EST) 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 BE11E6B0078 for ; Fri, 9 Feb 2024 05:40:38 -0500 (EST) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 96252A19E0 for ; Fri, 9 Feb 2024 10:40:38 +0000 (UTC) X-FDA: 81771921756.09.A0AF566 Received: from mail-vs1-f54.google.com (mail-vs1-f54.google.com [209.85.217.54]) by imf04.hostedemail.com (Postfix) with ESMTP id D9BED4000D for ; Fri, 9 Feb 2024 10:40:35 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=KEXjOJ7t; spf=pass (imf04.hostedemail.com: domain of aliceryhl@google.com designates 209.85.217.54 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=1707475235; 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=lsvt0WN0Q+3QLUT9l3zysLscG0T2/IlzfGAIXHSNZh0=; b=qVmIQI2lNJhGFfT/+kAFXHYgA4KdqzGe9zass/A5cbuU8lAqITibqKsZhePYfqe+nzNITs /Lf3t46EJqwChrsAMaJjXoYkRZssEwCk/nvooAaxvkhl7L1GOPqT0D/41CPJSHn1QKwTJt 4YHYcBsmaTS81bmxnDzR7pNnKbF4axY= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=KEXjOJ7t; spf=pass (imf04.hostedemail.com: domain of aliceryhl@google.com designates 209.85.217.54 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=1707475235; a=rsa-sha256; cv=none; b=SUwYenQx8JPGO/3EzqOTll/Kqyum6/d7zj2L+kqp+WVoyFVqNYTbC8FOC4Zwb/rkv0UasZ J9GKgXZjTLUvB08OHIXShqwIYHsj9lXR4068PiGYFfPfbaQaqIV8zTsY83FxHyXjq8UK1l Av3mBTsKCZ4awg1fLZzC0YwHhC2D9ss= Received: by mail-vs1-f54.google.com with SMTP id ada2fe7eead31-46d2085eeebso400372137.1 for ; Fri, 09 Feb 2024 02:40:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1707475235; x=1708080035; 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=lsvt0WN0Q+3QLUT9l3zysLscG0T2/IlzfGAIXHSNZh0=; b=KEXjOJ7timC6YyO85J0bs50dOm2klZUn25/rKB/LNutRgTJPMqLkY29WBed4usR7p5 aVNFm09uZmpe4eLdaE1NpmXT8IO172icelVJd1ITU7low87cVPo/0aCZOyLmPSfDdk6V v5QrJb+RnWVKv9eQRV49AntpJLhVSkc+YWBIYlAzLhhriKJtGQbyscU9dPGADdXMh/db gqL/pmT2HLsFQxvdqIjXP6OJ6Hqktre2pA9mxIf7HgbfH0efrysAzaqAdTbGDK7YTakR Qd4iPymD0Bgef2CoaqVEgzy0yREITRg7Upjtf3GcKBsx0zBFWX/rnhAoD91TEs8ys59t vTfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707475235; x=1708080035; 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=lsvt0WN0Q+3QLUT9l3zysLscG0T2/IlzfGAIXHSNZh0=; b=FThYMpq3OUqWINLGgqkE7E7RDbc6LEOpzuLho+LGaqHi6gSA+qNcyHZv24kJGodyNR ztFoXSkFSCo4A6B7L3qlRTR+vskPIVWD9oTEV/6N2IZUtLPAydhnGegoCPjCryrsFw/p wuBnLYsMU/wl2DWX0uyjlmxFlx2OkwMDHCFA4UizCEc+W8Z+0ddvVSq3HF292f9ua2G3 qe/XGE5BjPSPB/MhBhRqq3euSO9UoIESsqTZVTyEyzcpt26xMCTPCxE+/gfIvrprksWr SbWtSmmxbKPPFmQY7a5iHQuU2WF3vD8N/rwn0emfV0Oe384B125cR2h9JqJUXWCYLzoH vXNg== X-Gm-Message-State: AOJu0YxmlQiAQ92AIW03isPlb0w8alb2hgNEif9NXVo6jvUUWcLPEPDJ hNv058rZlansWoLW5tFI3pd68Qxf04h0ulWgKPHeJGvUEVEC+TOlz0RgPzbY0CmIUd+in1lVYYk l4PLLU0mBCwdvuVwsRhxXKNL9JCsUi6gXUV5d X-Google-Smtp-Source: AGHT+IGyJbE/oLWsC/siVXihK5czgIws1GI9FUcGNwzlxH+9vubxFLpJLPXCPZ83/8Qz0TPgrUwZqpCMEUYcw4ZCYrc= X-Received: by 2002:a05:6102:21c2:b0:46c:f91f:b03b with SMTP id r2-20020a05610221c200b0046cf91fb03bmr214596vsg.13.1707475234844; Fri, 09 Feb 2024 02:40:34 -0800 (PST) MIME-Version: 1.0 References: <20240208-alice-mm-v2-3-d821250204a6@google.com> <20240208225748.12031-1-kernel@valentinobst.de> In-Reply-To: <20240208225748.12031-1-kernel@valentinobst.de> From: Alice Ryhl Date: Fri, 9 Feb 2024 11:40:24 +0100 Message-ID: Subject: Re: [PATCH v2 3/4] rust: uaccess: 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: D9BED4000D X-Rspam-User: X-Stat-Signature: c5yri7zu1sud73fjq11m6jheydubndmx X-Rspamd-Server: rspam01 X-HE-Tag: 1707475235-114976 X-HE-Meta: U2FsdGVkX1+DQplxP6HtWHmSY/NDqdODMXlYKdgyO10Yu7Zp3yvMx2M9ov/MgFHXM+UZ0c+hRc3dSk8VJdvaul/uVjlR1LBf16FTlCuAsl0TPW8JDYokbNgilxG/GpK0aDJ+u5hd0wWFE7brAEcIrZm2b6V3fFavrG242ZlC3XVUzaKxATXlYgrXzhXBO2OlWI2P2aX6RYctmxu/I0kjjdZqpQw0ke52hu90msrGsEsZQmQTk/f2PICNciRsD0P+VEJZPgFNjTh70NiJKF8e1Q351FimY+w3qbrtvS3NaH+xHcXW6ckbjlc1ZHbUn+gfEVj8CP721+KDykEEMfRrVOUNLNqGqb5mrTcmUtGUoHC23sCsjlPC5vjg5rVtk9zqgkdglLU5dOEAU1arIhWwzqOuvnRBRuZ57S4CuV7n98MH3ZY/Bec/8dOmbRqjkx/bchnJlrN63ZT+i2pB/QcYP62Tfi+9K7lawpIovIOOLSwTLieM996yYRi6aMzMmEQj/LmYhlM+mbjTvyIp8XIoPH2lDFUG/6bt1dIee5KSI9alHO6ek4siRhqdcbMARnhclwYpVeK0PF+fltglQJLUrF6eshpzyctGQnA/MwbPy6HW3hQhQich1lZiPfT+oFo9jzAMpWw8ysW5p9MxF6WsIOWQWC08vEhBP3RF3sR5VKxEd/AbfAsrRe4t+p4uKPnBx/npoWf10b2Cim4rYYDzvz5z4O3fLmZwVzXpmEAuGDnPWIzX6SqVCm5YDD+n36G3KW9JOL1/jJTMYlj4sJOlVVExaH4hDCIezSbIJ34grvbg4mpR8rzU8NfcVMKjp0kClmFjkKWCt+urOGv/aRIa9R/gsJj21nINW7gnTs17avitK97iX1civp2nA+WH5CnwvHzJT6jBcjqiXawRUoXGu21uXhxpNfmJnMwDhKtIVBdHzQjYhs3qME0S3v/4HDjaxWqLplt/BUQT5Hoiae0 Ws0q2pur AqL8684fJu1rkUJtcjWZH/NgQdapVm47oQZT6rwUIGvlPTx0/zR2yaeak5KyVeX0KsNbmDwsQKI4+LXuhGlexfQHuVP+A0tq+QYljAt0c/8v7PLYq2u/+k/Ow75uewfgJx/1YIM09m/RWLVq7oGa58j7VHDPU2oRufhijGYUXDdoKBS8axqMZA2iMYicKZN/EPKTqZZQbSzALHc8ouDcxXKTpk0Z39nLah0OXJ10pldRg6pFtH4y6BdUHx7V2p4f9+Yg8hWiz4jZg6XLCR81l9/luNSDm60lTYFnvgAbSGRnRzjA= X-Bogosity: Ham, tests=bogofilter, spamicity=0.001224, 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, Feb 8, 2024 at 11:57=E2=80=AFPM Valentin Obst wrote: > > > +/// If a struct implements this trait, then it is okay to copy it byte= -for-byte > > +/// to userspace. This means that it should not have any padding, as p= adding > > +/// bytes are uninitialized. Reading uninitialized memory is not just = undefined > > +/// behavior, it may even lead to leaking sensitive information on the= stack to > > +/// userspace. > > This feels a bit too restrictive to me. Isn't it okay to copy types with > padding if it is ensured that the padding is always initialized? > > I recall that in C one occasionally does a `memset` for structs that are > copied to user space. I imagine that one could have a Rust > abstraction/macro that makes it easy to define custom types that can > always guarantee that all padding bytes are initialized. Such types > would then qualify for being copied to user space if all field do so as > well. > > This could be a significant quality-of-life improvement for drivers > as it can be tedious to define struct without padding. I don't think we should go that route. For example: let struct_1 =3D ..; memset(&mut struct_1, 0); let struct_2 =3D struct_1; Even though struct_1 has its padding zeroed here, that is not the case for struct_2. When Rust performs a typed copy/move, the padding is not copied. Anyway, there is a work-around. Define your struct with MaybeUninit: // INVARIANT: All bytes always initialized. struct MyWrapper(MaybeUninit); impl Default for MyWrapper { fn default() -> Self { MyWrapper(MaybeUninit::zeroed()) } } Unlike the bare struct, things wrapped in MaybeUninit always have their padding preserved. Then, you can implement the trait for this wrapper, since its padding is always initialized even if that is not true for the wrapped struct. Alice