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 66E85CA0ED3 for ; Mon, 2 Sep 2024 15:26:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A482F8D0098; Mon, 2 Sep 2024 11:26:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A1E6E8D00E9; Mon, 2 Sep 2024 11:26:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8BDD48D0098; Mon, 2 Sep 2024 11:26:20 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 6B1CB6B00BD for ; Mon, 2 Sep 2024 11:26:20 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id D29BC8020D for ; Mon, 2 Sep 2024 15:26:19 +0000 (UTC) X-FDA: 82520174478.13.7D79BAA Received: from mail-pl1-f178.google.com (mail-pl1-f178.google.com [209.85.214.178]) by imf18.hostedemail.com (Postfix) with ESMTP id C07DA1C001B for ; Mon, 2 Sep 2024 15:26:17 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=osandov-com.20230601.gappssmtp.com header.s=20230601 header.b=T6DK8jvq; spf=none (imf18.hostedemail.com: domain of osandov@osandov.com has no SPF policy when checking 209.85.214.178) smtp.mailfrom=osandov@osandov.com; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1725290730; a=rsa-sha256; cv=none; b=ExvoLRwm+59wym6hd321ZmRnjForZKEY1mxEeFVWF8bVxFQpNzyAPmDz5rKuv9IfZ1a/Ww ymzPTzHskITdHWzMsJA3ZuP9krHSKdseniP/nIrgd8Jp85NAkaDi3r1TOn8F+Tf20B7s1W gVKF0asUosWVr5L9IfLRVezHfgkMeh8= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=osandov-com.20230601.gappssmtp.com header.s=20230601 header.b=T6DK8jvq; spf=none (imf18.hostedemail.com: domain of osandov@osandov.com has no SPF policy when checking 209.85.214.178) smtp.mailfrom=osandov@osandov.com; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1725290730; 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=mQrdUk9Qs95YbYxvkhvXPIF077+rLJVqqSG6sH4DY10=; b=he0yC5QZjg5adM6El2JxdxvPnJsVUeJy/34Tig0Ij3BpqvsJ5VPpcgkmiovmaBMeqgOyqt ZsjOnSCDpCYw2pE2Borptzw7l/iy1yhV6vzWGfwd+XBIa5RrqkT8oMTGjNZG9VJbbCy0q8 5Kc6imbTMCUoGLQRwlj6W0nz93Pb3iE= Received: by mail-pl1-f178.google.com with SMTP id d9443c01a7336-205557f9699so2667775ad.2 for ; Mon, 02 Sep 2024 08:26:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=osandov-com.20230601.gappssmtp.com; s=20230601; t=1725290776; x=1725895576; darn=kvack.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=mQrdUk9Qs95YbYxvkhvXPIF077+rLJVqqSG6sH4DY10=; b=T6DK8jvqa6m7shbV9Y9vZfY5vVn15OKiDrubCTIWOn6GW7ZS3dAMecvxW9uS1VH0Pn CcHM0naRrmENEKDEXgCAygqt9ccjhhdfH9obiF9HVRqRs8Jyee1t547jANShcCXJ6Cap DUJa6amIkrO7P1LsDQo3/P3bnuZ3rvE0mUCeR4dT/KxZ2Jg98RBr/ofDW/Ib66cAs+0o A/A8dBCS2M8SmXdS8pXWuHpOwJbiNCwlMaqsv4jZ/ms34yZB7CyMZq3IVUw4pofEGWZg TTpZ33JLmiIHRvSar9RF7MmqYPLFT0oQRGB0Y8fHteeW8B1uGneRyOcokF/RZ9JtiH3q NU6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725290776; x=1725895576; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=mQrdUk9Qs95YbYxvkhvXPIF077+rLJVqqSG6sH4DY10=; b=pvy9z7YSiUOwIiPKxRngwMZtc20Ye42dwKIvtlYOLt9To/5wid2nbEmoDJP9EVonos /Wng6JKW0oTRj+9GTeAGlDzp3fUTyV1RHhAG3Kxhi/KdWCBQxHOSwMAzAiAH/ll5vDAn pC1t1747y8fc/1gPql3xKIfB9Ydg820t6jb1HIeaYcPTDUyqDIX9Gk/KOJOI628UdyE7 enUNvX2YVmcmFlp71Yy6uhpvjBlgInEd2sc48K3q78W2xiCxg1TkpO2vxY90kz8v3xxD IK13vPs5fxQxKxr9HWOmMek/pB4sy5SbymEvnCEEDDpJ+Wld2Xy577MPjplPEGXKh9JB Y35A== X-Forwarded-Encrypted: i=1; AJvYcCVVIJHS7OsCv3zZ05UeKv9cMOlFz4grp5gzQKaKTPRc2KEaXXDshu4gipEoqNfrIzxIEg/Ozxaf4Q==@kvack.org X-Gm-Message-State: AOJu0YzRoVm9JuNkYoziYRdTPhXfoHcRCsAG8Ec2sAjXR/bExkB4TWvW OSbA56KwsxZESKW+EAtC+162WZ7ERWyxTGrIUNv3pKmhb7chKAes/2dlXunzRq8= X-Google-Smtp-Source: AGHT+IEIj7UpxJT8a0mIACuZXNoTi9evmUotnGeb8wHYPTVQQPCrd38PWufROqKQIhaL5lvUsVlKgg== X-Received: by 2002:a17:902:e549:b0:205:8948:3578 with SMTP id d9443c01a7336-20589483694mr10763885ad.2.1725290776144; Mon, 02 Sep 2024 08:26:16 -0700 (PDT) Received: from telecaster ([2601:602:8980:9170::901f]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-205152d04a3sm67470855ad.110.2024.09.02.08.26.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Sep 2024 08:26:14 -0700 (PDT) Date: Mon, 2 Sep 2024 08:26:13 -0700 From: Omar Sandoval To: David Hildenbrand Cc: Christophe Leroy , linux-mm@kvack.org, Andrew Morton , Christoph Hellwig , x86@kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, loongarch@lists.linux.dev, linux-mips@vger.kernel.org, linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-um@lists.infradead.org, kernel-team@fb.com Subject: Re: [PATCH 0/2] mm: make copy_to_kernel_nofault() not fault on user addresses Message-ID: References: <5fa50d78-6764-4f99-87b3-7bd7edbeea5a@csgroup.eu> <861d448c-ce1d-4b74-87eb-9b211dfebbb1@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <861d448c-ce1d-4b74-87eb-9b211dfebbb1@redhat.com> X-Stat-Signature: pw551bb8js4dqzny7kzc1j9tjezto3o1 X-Rspamd-Queue-Id: C07DA1C001B X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1725290777-278354 X-HE-Meta: U2FsdGVkX19xQNqTbBuaskZOOHXzavXTPADThVYwQqLu1R+L/ipuy8hjMGaHcZxjEknubKgEkOF7/dL3H8zvxJJwLYwEVZg5qoFTCAGRaf0ZVBExL1j2L9o+4HABeqro3Z3I9K4TODKbub2JHrdA2cqqKNsHAB1jRzAIRZtWWN2KuNNUc8D8QXiRxACkAWK19TGc/eUDFheFtB2jkjTQ/Cl46FiyE3kWggqm+xXmw6R88smbWa34EoPGc5TnLcVp9W7iQxJMhDrAouUgVz5I+eDwaQ8LZOTItcUOOZSM/0m9unzlc1hrc36lO/Wz94NRm/Kz57ikb0HcA34kCqBNpfbW8Pkw3r6a9H4yMgiQMxJed4m/jQWhMV5qmQWU7u4XD6K9Ah83W6e0xdBHnm1IUw/Oz14oYeY2pNiOMqCG+xSeWFEqo3o2fAo5K2F5DBYx0+DlDNtVEvnZ7FNF5zQUmb0au/M5yrIX9uSYGMppA4anHvu471/3tu9S9k147MkYgvLwEgifK0oBjJOMOHQggqzq1gtBOqp5ZDdkfU3lyKScxMolfxy5JNNaFgKWWoa88oVMyIcM2RdDWSSgMQZgYqkmg0adc4YE6iSeMOK8kyvsTyRCgnTfqEmONyUEjviKivUKsMRMWWoz4wqdwG/nW3fFoge5Bri6aptKXNkfI5t64VGgahpqG5fmMX7/1E3g50p91npG2JuRF/zvk1zoP1XEiJv3IpuqLQ4qHAhGXY+zA81z1Oz/mpG9luthlKGnDF3shWY0oPkLi8/UKfqNzKrLCccf23duvzpFMiYhUYyuYe69bd4JDRrUXC3VvOq11DRRXSNFxUZwMTPVH8XfE/E9oovxOddu+ZERqrFhWA/W0RwWGc7qW5kPRcrLIWxui+4RElH7gYcKewWKsVTl9ukS4i7wjtFrt1qfBkc/l88fTsQzwQMb3FoEliuCj3DwQzxbxZ3xug5sdD6lBdF knDCAif2 DYeynOujY35tdwCfIqLENSWfcBs7Yi8Ubj0yJ2ybEwBjtuM2B0TJuXi+3hklFfvOfphbJRGH7bSPaq9fLzk9J3TxpF2ULuGNYHZf7/08lDzCBm2rAaqp+5gwrsWy94l8K3GTt56sBy1qscJ9HTH5m4Q8fPBAnQvYoERnMsD0tuxPmgvLJNbilMgFLGzHQocf/sQTFOGrgNqO0qfjrmsDZ/92qACkBhlz7GrPnYXUMrGCWRImzZKTugpc2ifUos6c8SpR2vYC1ilyKhbJTVmc0wK+z9jrsq7PDMqxheY9XxSreXvaLuF2saNl8MwPgPkmlrlNZyA1zgf/fRZSBMv/kYL/isGqfWa2OzRAx3i5w7PesF2ZXaubkF8jNyt5YqT9x/tR5exzZ4u5rwgU54zfmNmry8WXxstDff8udhuBT1Yi8xjvCLSQxHS/RzVPsUpkFZPLY4ESFhhsuCNOj/4C/pRTD3TgKbj9dnpSd0qde5GG+uJOomrUEKXphRuf4y7QIdxBo0JKvLiAXqvFF5y95777qGjXO2JKH4exFsfaGVZQXvVthn2q+AVP7/A== 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, Sep 02, 2024 at 10:56:27AM +0200, David Hildenbrand wrote: > On 02.09.24 08:31, Omar Sandoval wrote: > > On Mon, Sep 02, 2024 at 08:19:33AM +0200, Christophe Leroy wrote: > > > > > > > > > Le 02/09/2024 à 07:31, Omar Sandoval a écrit : > > > > [Vous ne recevez pas souvent de courriers de osandov@osandov.com. Découvrez pourquoi ceci est important à https://aka.ms/LearnAboutSenderIdentification ] > > > > > > > > From: Omar Sandoval > > > > > > > > Hi, > > > > > > > > I hit a case where copy_to_kernel_nofault() will fault (lol): if the > > > > destination address is in userspace and x86 Supervisor Mode Access > > > > Prevention is enabled. Patch 2 has the details and the fix. Patch 1 > > > > renames a helper function so that its use in patch 2 makes more sense. > > > > If the rename is too intrusive, I can drop it. > > > > > > The name of the function is "copy_to_kernel". If the destination is a user > > > address, it is not a copy to kernel but a copy to user and you already have > > > the function copy_to_user() for that. copy_to_user() properly handles SMAP. > > > > I'm not trying to copy to user. I am (well, KDB is) trying to copy to an > > arbitrary address, and I want it to return an error instead of crashing > > if the address is not a valid kernel address. As far as I can tell, that > > is the whole point of copy_to_kernel_nofault(). > > The thing is that you (well, KDB) triggers something that would be > considered a real BUG when triggered from "ordinary" (non-debugging) code. If that's the case, then it's a really weird inconsistency that it's OK to call copy_from_kernel_nofault() with an invalid address but a bug to call copy_to_kernel_nofault() on the same address. Again, isn't the whole point of these functions to fail gracefully instead of crashing on invalid addresses? (Modulo the offline and hwpoison cases you mention for /proc/kcore.) > But now I am confused: "if the destination address is in userspace" does not > really make sense in the context of KDB, no? > > [15]kdb> mm 0 1234 > [ 94.652476] BUG: kernel NULL pointer dereference, address: > 0000000000000000 > > Why is address 0 in "user space"? "Which" user space? Sure, it's not really user space, but it's below TASK_SIZE_MAX, so things like handle_page_fault() and fault_in_kernel_space() treat it as if it were a user address. I could s/userspace address/address that is less than TASK_SIZE_MAX or is_vsyscall_vaddr(address)/. > Isn't the problem here that KDB lets you blindly write to any non-existing > memory address? > > > Likely it should do some proper filtering like we do in fs/proc/kcore.c: > > Take a look at the KCORE_RAM case where we make sure the page exists, is > online and may be accessed. Only then, we trigger a > copy_from_kernel_nofault(). Note that the KCORE_USER is a corner case only > for some special thingies on x86 (vsyscall), and can be ignored for our case > here. Sure, it would be better to harden KDB against all of these special cases. But you can break things in all sorts of fun ways with a debugger, anyways. The point of this patch is that it's nonsense that a function named copy_to_kernel_nofault() does indeed fault in a trivial case like address < TASK_SIZE_MAX. Thanks, Omar