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 D4C52C46CD2 for ; Wed, 24 Jan 2024 23:47:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F14946B0071; Wed, 24 Jan 2024 18:47:10 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id EC4FB6B0072; Wed, 24 Jan 2024 18:47:10 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D64616B0074; Wed, 24 Jan 2024 18:47:10 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id C6FC86B0071 for ; Wed, 24 Jan 2024 18:47:10 -0500 (EST) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 6814CA236D for ; Wed, 24 Jan 2024 23:47:10 +0000 (UTC) X-FDA: 81715843020.25.C76E787 Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.131]) by imf04.hostedemail.com (Postfix) with ESMTP id 69AA140021 for ; Wed, 24 Jan 2024 23:47:08 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf04.hostedemail.com: domain of kernel@valentinobst.de designates 212.227.126.131 as permitted sender) smtp.mailfrom=kernel@valentinobst.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706140028; 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-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=FoRb3CjNMY6M5Xaqu9nMysyYX4s/oiufWNZJpWBigdc=; b=dRJiYrR9UuX9+YGBoLEG9gMqjfZ43mLTX96GvnVVkmcUD80YAWUNsbVtJhxT9wPCbIOBCN RYoHtZQ9cir1/EclUohvLfnVUizRQ0pYJFvppy9adbSKk2HFXcXUPFYcMAfQU/dVRtK2mp 2P18BO/ho7SciP//gMTUioV5vv/A7r8= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf04.hostedemail.com: domain of kernel@valentinobst.de designates 212.227.126.131 as permitted sender) smtp.mailfrom=kernel@valentinobst.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706140028; a=rsa-sha256; cv=none; b=ckeG54wDP1pKqTbuGnrAS9I+L9vtGwD2gJZMq5UjEI835AMFFXov2aaigSsptzMDG8/9du MtWYD/l/qaYBTEfaoJ4YY3pyRGwGE2HUg6MQ9rQDaviQVO9yIvKmRBxh0l42i3QabLwXV2 EapVJV01EkXdTICVltz+teD/Cl9IjvI= Received: from localhost.localdomain ([217.249.70.154]) by mrelayeu.kundenserver.de (mreue012 [213.165.67.97]) with ESMTPSA (Nemesis) id 1N0Ip5-1r87RC0iXf-00xKBP; Thu, 25 Jan 2024 00:47:01 +0100 From: Valentin Obst To: aliceryhl@google.com 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, Valentin Obst Subject: Re: [PATCH 2/3] rust: add typed accessors for userspace pointers Date: Thu, 25 Jan 2024 00:46:26 +0100 Message-ID: <20240124234626.6435-1-kernel@valentinobst.de> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240124-alice-mm-v1-2-d1abcec83c44@google.com> References: <20240124-alice-mm-v1-2-d1abcec83c44@google.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K1:Gd8dUn8DsdiwfILUeWWL1kxjPxPP600vXTnWpKQGJW/qHXjgV+z 8+geoeA63GhPacHwaRfW5f5cYPK9k0eLyL4GsVfgq50Sg/prvcA2u4loKRolU58O3fB/iOo 0lUXnI7FXu1dd8QCOAHYGK4qk3BdCTrdKSDgwjcuDmc5a73VEgPw4mW0NkLt3tP+K7bHWMu HLNLlk4KM0cJzgVzCb6yA== UI-OutboundReport: notjunk:1;M01:P0:qOJAcrdou2M=;U0Dgh275qiGV8d0f5l3kP4AgC3N dpuFzkK8EeFuTRmZguWloob/taf4BCRg73JNxcTRGnFG4IsyfS2xM6mo3g7gdgC7KKmP8O7vr jkXsNC3KDKUVoi+h02BFDtui7JFfoKKI8YTrTTltKEhnbxAuQqgker5r+c3XCidZnBkDnlg7g yGvWvLR1L92GIQI/mN5/4B7cM3QnPcxtghCuk1hhlHOM3l20AkMLxDyV2CNwN7BakKqeXfCI2 pozPiK26iUgGPoQROCqk/zvIHlOic2pHM2ZelDfp6vYu4EAdqtA5HmOcN0zKXdGe4+hL5uy+6 oO5PAE2L2zsj4u6MzGJ6QByl/hvea+C168Xct0g7WK0PIOTAu7NKCdp3KirG6SD+zujeKfkNb D6Nzqiq/d5GqDI2daOc/OUEUt0WViyAj5j110/QW77PqQeqqMYWg58I0N1wKMEF5hFp2aa+Xo RhQkP0QNkb8wbF6JzGBBnh1lnnq4l3wsYSybG94o3SC6PnakBm8KVWQxUL1YPlxDERETNbzEx f3g5QoXIPUwG6sz2F7VcdXtY3MdpKmpfuOLNAEQ208HdNhm3yRboHUuJPNy22cCI9UQhRYgQs j1RTR4VTn6ycX/BIo12k7U00Jz1BvNx7Kk6TPd7i/tj3ebHKJiMLo6gPSxJqPpjwSB1QA9dLH vvH5TQPGeNFRtZuWDnUhhvl79CPGdoIK3oAOGWp7Y/vO3lgddnWEeMqluQZTOmIiE2agSM0U4 W7/KPe4f1eEjCPwz1XubXQHBWhrzqPlO3liEQJG1Hyem6JdzypXgzVRxQr+W33bXzaJmir0hg uwg5F2ppVt3e+UCKmPyd+rpgXk/zgcA2E4LeIEb21ApdC8fY/lPnn/bBHQrt7f9Ah664pgfku ovzjl0zElPtdz8g== X-Rspamd-Queue-Id: 69AA140021 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: 4wo9wufejnkdm19ko6eohhdqibea5ufs X-HE-Tag: 1706140028-118743 X-HE-Meta: U2FsdGVkX1/vbr0sRx2DlzcxVAA964R4RY5fOPHW1sb30r2l6YxVmu8afGbwAIFbRI/kllQ85M475DCoE/17gsPNcNlgenkoaqkNwT6rfSTskxe6XS7lMLE4wiJNhdRnyxaZQoPyDoJqisWz+KG4is9vIdUfLZV/xva25ywuCMP3k2BKGadWn0NQmllYYOsiiccxEI96ruVoQho6BiLAc7Pf3gBQZyeFq20Wz3okU9NM64LGN0URVNJ1HG8N5oXs/TqM+sxcmM8Ee28V/IxA/NeM1Y17nOFFs6GRJQG0190UlBubGC+LhhERhtpnX0cMClinfVBPmxw2X/HlBQRNliUja8zfAI/fpALqnxom9PmnIvDrTsgaBIQ6QpRe50bHEnI6zh61T+hPac6DPib+aeW4oJScejOoE4VHCP6oH9Q3B61K1J54/dLNIPylGIKKHL7oRmYkB0oDG2yNzCkE6XGYcyMpiYQRzkCmx/3DC9/DEPWcjeZvd9x2uhYuHw+1rRLIiU8ymHuI0e7eRChMlhuUGbHevraEt1gWcWpiymSaIOuyzi8XnvJB8vQiSQ0yO7E0qYVdnOvGv4lUWoMD33I2i+MCAOQuhDw3TJcprHOEjOriblIAjcNSOf9Ks/eTjNvgvcOmcNHUB3G+EFvEp7ESTmh/Dl9JQ9xRUv0uvHPB5bVa2Dk84Ph8DJquSEbr2JrvqqivSBREXUfUnSaHa6MEAp0CHoQ3sY9oIcNTUlXjgTh749ePJGAc6feR6jBdYPANLiBSXd3bLDB0FBfw2V+5YsLR2DhTNiU/DScvGCi/kUlkUl5ES4dz1RLndsyIjBBOYUSd4ixvOKUzKRTFhlUTrElrLKXLnMg34Edt/V589yXArjkMbLbESRqTvBiBjlTN5eSGob86QPeodKs3DjxubcNeyhOKSwDLnCcf4q45hZvNzcMnhAFEQWr5IU357LjP1Po//wmv87MUIoT d3Zv4f0a e3A8eNsKr5qQyKwEoeTQN6M87Mk7jY2OIIjen1bFCWlmXRpxbKtkV11QYwJBOwHr/sdUoh5FoCdxWwNaJsTWi/ZRU1haqEc/Y7CnGdHKCjJCPqtw2i2Yaf0MB+9jYGO14buWBSORYqCjNua+REIrCES5uX4yORES7+KCZNmwW2oeZaDo4TKqZvck6c9Ecmm1RCjURxfSZhlXlltTbZALnxSxB0LkLV3cnriFgCq46mA4Jv1WOYyRjYu+2WU93WGWGtZY6 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: > +/* 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|from]_user` > + * normally performs. nit: They skip the (stronger, and also present without usercopy hardening) `check_copy_size` wrapping that one. > In C, these checks are skipped whenever the length is a > + * compile-time constant, since when that is the case, the kernel pointer > + * 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 the 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. > + * > + * These helpers serve the same purpose in Rust. Whenever the length is 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 = 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(void __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_size); Could those be wrapping `_copy_[to|from]_user` instead? - Valentin