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 DA960C433F5 for ; Fri, 18 Feb 2022 07:30:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 685806B0074; Fri, 18 Feb 2022 02:30:20 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 60DA76B0075; Fri, 18 Feb 2022 02:30:20 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 487296B0078; Fri, 18 Feb 2022 02:30:20 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0188.hostedemail.com [216.40.44.188]) by kanga.kvack.org (Postfix) with ESMTP id 35B526B0074 for ; Fri, 18 Feb 2022 02:30:20 -0500 (EST) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id DDE36181AC9C6 for ; Fri, 18 Feb 2022 07:30:19 +0000 (UTC) X-FDA: 79155077358.22.1F688AB Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf26.hostedemail.com (Postfix) with ESMTP id 55506140006 for ; Fri, 18 Feb 2022 07:30:19 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 809EC61F0A for ; Fri, 18 Feb 2022 07:30:18 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3FF06C36AE2 for ; Fri, 18 Feb 2022 07:30:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1645169417; bh=4Rk51yI7cy+h8GrR+wkZuFO6d6ZOgVmodthZQla/xGE=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=W+QkvboqRofbLzCm9hHbzxq3Qth8S5HybnqRYBMCOV1+sxzSrsO0GxsWzCKKMdHEn bqDIEx/e5uKVtXdEgKU0zauKVsAP+BwRxL7Eht14lnrZY8/Snkv6ooC0Xtnb3PIWOU TH9CI9oqKC4NB6YlmX9GiyVVlzJ9JxhHp19vd8W2yF7M0r4JQcSsxSZGgcunHmnBls jIKpwMz+6/fED/WEoZ31MUXYk0elz6QstAQFVIrh0vdiPiG2fQNGZe4Ls/9ylnZeuT EPDfxlf0eA4H0vr8C6AxZVCkxFWsivLQ9riuK2cmIaTDgPv5zksZWQSERe1IxP+qyj OVCD1xp4hu7Yg== Received: by mail-wr1-f51.google.com with SMTP id e3so13072555wra.0 for ; Thu, 17 Feb 2022 23:30:17 -0800 (PST) X-Gm-Message-State: AOAM53140T+9AMTczgYdzk0HOamxD7nTGhiIP9XG7AXLr9m5QIoJ5emN c4rlyf4zWqMoo7azf9u5F1nG6vjVPShlfhZH+CI= X-Google-Smtp-Source: ABdhPJz4trlMwdvjT8y0UPggztkdijECp2hMuaf6QP4pGa8b+VYFZp4/tSgCA0YRdkm1OA4dObRIZr3wh6XhtS+RfLY= X-Received: by 2002:adf:ea01:0:b0:1e4:b3e6:1f52 with SMTP id q1-20020adfea01000000b001e4b3e61f52mr4942117wrm.317.1645169415535; Thu, 17 Feb 2022 23:30:15 -0800 (PST) MIME-Version: 1.0 References: <20220216131332.1489939-1-arnd@kernel.org> <20220216131332.1489939-6-arnd@kernel.org> <20220218062851.GC22576@lst.de> In-Reply-To: <20220218062851.GC22576@lst.de> From: Arnd Bergmann Date: Fri, 18 Feb 2022 08:29:59 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 05/18] x86: remove __range_not_ok() To: Christoph Hellwig Cc: Linus Torvalds , linux-arch , Linux-MM , Linux API , Arnd Bergmann , Linux Kernel Mailing List , Al Viro , Russell King - ARM Linux , Will Deacon , Guo Ren , Brian Cain , Geert Uytterhoeven , Michal Simek , Thomas Bogendoerfer , Nick Hu , Greentime Hu , Dinh Nguyen , Stafford Horne , Helge Deller , Michael Ellerman , Peter Zijlstra , Ingo Molnar , Mark Rutland , Heiko Carstens , Rich Felker , David Miller , Richard Weinberger , "the arch/x86 maintainers" , Max Filippov , "Eric W . Biederman" , Andrew Morton , Ard Biesheuvel , alpha , "open list:SYNOPSYS ARC ARCHITECTURE" , linux-csky@vger.kernel.org, "open list:QUALCOMM HEXAGON..." , linux-ia64@vger.kernel.org, linux-m68k , "open list:BROADCOM NVRAM DRIVER" , Openrisc , Parisc List , linuxppc-dev , linux-riscv , linux-s390 , Linux-sh list , sparclinux , linux-um , "open list:TENSILICA XTENSA PORT (xtensa)" , Christoph Hellwig Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 55506140006 X-Stat-Signature: 75exwr441kzsm8uyd6a8q8getd8ia8sj X-Rspam-User: Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=W+Qkvboq; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf26.hostedemail.com: domain of arnd@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=arnd@kernel.org X-Rspamd-Server: rspam03 X-HE-Tag: 1645169419-280080 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: On Fri, Feb 18, 2022 at 7:28 AM Christoph Hellwig wrote: > On Wed, Feb 16, 2022 at 02:13:19PM +0100, Arnd Bergmann wrote: > > --- a/arch/x86/events/core.c > > +++ b/arch/x86/events/core.c > > @@ -2794,7 +2794,7 @@ perf_callchain_kernel(struct perf_callchain_entry_ctx *entry, struct pt_regs *re > > static inline int > > valid_user_frame(const void __user *fp, unsigned long size) > > { > > - return (__range_not_ok(fp, size, TASK_SIZE) == 0); > > + return __access_ok(fp, size); > > } > > valid_user_frame just need to go away and the following __get_user calls > replaced with normal get_user ones. As I understand it, that would not work here because get_user() calls access_ok() rather than __access_ok(), and on x86 that can not be called in NMI context. It is a bit odd that x86 is the only architecture that has this check, but adding it was clearly intentional, see 7c4788950ba5 ("x86/uaccess, sched/preempt: Verify access_ok() context"). > > diff --git a/arch/x86/kernel/dumpstack.c b/arch/x86/kernel/dumpstack.c > > index 53de044e5654..da534fb7b5c6 100644 > > --- a/arch/x86/kernel/dumpstack.c > > +++ b/arch/x86/kernel/dumpstack.c > > @@ -85,7 +85,7 @@ static int copy_code(struct pt_regs *regs, u8 *buf, unsigned long src, > > * Make sure userspace isn't trying to trick us into dumping kernel > > * memory by pointing the userspace instruction pointer at it. > > */ > > - if (__chk_range_not_ok(src, nbytes, TASK_SIZE_MAX)) > > + if (!__access_ok((void __user *)src, nbytes)) > > return -EINVAL; > > This one is not needed at all as copy_from_user_nmi already checks the > access range. Ok, removing this. > > diff --git a/arch/x86/kernel/stacktrace.c b/arch/x86/kernel/stacktrace.c > > index 15b058eefc4e..ee117fcf46ed 100644 > > --- a/arch/x86/kernel/stacktrace.c > > +++ b/arch/x86/kernel/stacktrace.c > > @@ -90,7 +90,7 @@ copy_stack_frame(const struct stack_frame_user __user *fp, > > { > > int ret; > > > > - if (__range_not_ok(fp, sizeof(*frame), TASK_SIZE)) > > + if (!__access_ok(fp, sizeof(*frame))) > > return 0; > > Just switch the __get_user calls below to get_user instead. Same as the first one, I think we can't do this in NMI context. Arnd