From: Arnd Bergmann <arnd@kernel.org> To: Daniel Thompson <daniel.thompson@linaro.org> Cc: "Russell King (Oracle)" <linux@armlinux.org.uk>, Arnd Bergmann <arnd@arndb.de>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Linux ARM <linux-arm-kernel@lists.infradead.org>, linux-arch <linux-arch@vger.kernel.org>, Linux-MM <linux-mm@kvack.org>, Alexander Viro <viro@zeniv.linux.org.uk>, Linus Walleij <linus.walleij@linaro.org> Subject: Re: [PATCH v5 08/10] ARM: uaccess: add __{get,put}_kernel_nofault Date: Thu, 13 Jan 2022 12:14:50 +0100 [thread overview] Message-ID: <CAK8P3a0=OkFcKbL+utDPTPf+RskFNdR8Vt-3BEWkO9g_FqSj5w@mail.gmail.com> (raw) In-Reply-To: <20220113094754.6ei6ssiqbuw7tfj7@maple.lan> On Thu, Jan 13, 2022 at 10:47 AM Daniel Thompson <daniel.thompson@linaro.org> wrote: > On Wed, Jan 12, 2022 at 06:08:17PM +0000, Russell King (Oracle) wrote: > > > The kernel attempted to access an address that is in the userspace > > domain (NULL pointer) and took an exception. > > > > I suppose we should handle a domain fault more gracefully - what are > > the required semantics if the kernel attempts a userspace access > > using one of the _nofault() accessors? > > I think the best answer might well be that, if the arch provides > implementations of hooks such as copy_from_kernel_nofault_allowed() > then the kernel should never attempt a userspace access using the > _nofault() accessors. That means they can do whatever they like! > > In other words something like the patch below looks like a promising > approach. Right, it seems this is the same as on x86. > From f66a63b504ff582f261a506c54ceab8c0e77a98c Mon Sep 17 00:00:00 2001 > From: Daniel Thompson <daniel.thompson@linaro.org> > Date: Thu, 13 Jan 2022 09:34:45 +0000 > Subject: [PATCH] arm: mm: Implement copy_from_kernel_nofault_allowed() > > Currently copy_from_kernel_nofault() can actually fault (due to software > PAN) if we attempt userspace access. In any case, the documented > behaviour for this function is to return -ERANGE if we attempt an access > outside of kernel space. > > Implementing copy_from_kernel_nofault_allowed() solves both these > problems. > > Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org> Reviewed-by: Arnd Bergmann <arnd@arndb.de>
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@kernel.org> To: Daniel Thompson <daniel.thompson@linaro.org> Cc: "Russell King (Oracle)" <linux@armlinux.org.uk>, Arnd Bergmann <arnd@arndb.de>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Linux ARM <linux-arm-kernel@lists.infradead.org>, linux-arch <linux-arch@vger.kernel.org>, Linux-MM <linux-mm@kvack.org>, Alexander Viro <viro@zeniv.linux.org.uk>, Linus Walleij <linus.walleij@linaro.org> Subject: Re: [PATCH v5 08/10] ARM: uaccess: add __{get,put}_kernel_nofault Date: Thu, 13 Jan 2022 12:14:50 +0100 [thread overview] Message-ID: <CAK8P3a0=OkFcKbL+utDPTPf+RskFNdR8Vt-3BEWkO9g_FqSj5w@mail.gmail.com> (raw) In-Reply-To: <20220113094754.6ei6ssiqbuw7tfj7@maple.lan> On Thu, Jan 13, 2022 at 10:47 AM Daniel Thompson <daniel.thompson@linaro.org> wrote: > On Wed, Jan 12, 2022 at 06:08:17PM +0000, Russell King (Oracle) wrote: > > > The kernel attempted to access an address that is in the userspace > > domain (NULL pointer) and took an exception. > > > > I suppose we should handle a domain fault more gracefully - what are > > the required semantics if the kernel attempts a userspace access > > using one of the _nofault() accessors? > > I think the best answer might well be that, if the arch provides > implementations of hooks such as copy_from_kernel_nofault_allowed() > then the kernel should never attempt a userspace access using the > _nofault() accessors. That means they can do whatever they like! > > In other words something like the patch below looks like a promising > approach. Right, it seems this is the same as on x86. > From f66a63b504ff582f261a506c54ceab8c0e77a98c Mon Sep 17 00:00:00 2001 > From: Daniel Thompson <daniel.thompson@linaro.org> > Date: Thu, 13 Jan 2022 09:34:45 +0000 > Subject: [PATCH] arm: mm: Implement copy_from_kernel_nofault_allowed() > > Currently copy_from_kernel_nofault() can actually fault (due to software > PAN) if we attempt userspace access. In any case, the documented > behaviour for this function is to return -ERANGE if we attempt an access > outside of kernel space. > > Implementing copy_from_kernel_nofault_allowed() solves both these > problems. > > Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org> Reviewed-by: Arnd Bergmann <arnd@arndb.de> _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-01-13 11:15 UTC|newest] Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-07-26 14:11 [PATCH v5 00/10] ARM: remove set_fs callers and implementation Arnd Bergmann 2021-07-26 14:11 ` Arnd Bergmann 2021-07-26 14:11 ` [PATCH v5 01/10] mm/maccess: fix unaligned copy_{from,to}_kernel_nofault Arnd Bergmann 2021-07-26 14:11 ` [PATCH v5 01/10] mm/maccess: fix unaligned copy_{from, to}_kernel_nofault Arnd Bergmann 2021-07-26 14:11 ` [PATCH v5 02/10] ARM: traps: use get_kernel_nofault instead of set_fs() Arnd Bergmann 2021-07-26 14:11 ` Arnd Bergmann 2021-07-26 14:11 ` [PATCH v5 03/10] ARM: oabi-compat: add epoll_pwait handler Arnd Bergmann 2021-07-26 14:11 ` Arnd Bergmann 2021-07-26 14:11 ` [PATCH v5 04/10] ARM: syscall: always store thread_info->abi_syscall Arnd Bergmann 2021-07-26 14:11 ` Arnd Bergmann 2023-08-03 23:17 ` Kees Cook 2023-08-03 23:17 ` Kees Cook 2023-08-04 8:13 ` Kees Cook 2023-08-04 8:13 ` Kees Cook 2023-08-09 19:42 ` Arnd Bergmann 2023-08-09 19:42 ` Arnd Bergmann 2021-07-26 14:11 ` [PATCH v5 05/10] ARM: oabi-compat: rework epoll_wait/epoll_pwait emulation Arnd Bergmann 2021-07-26 14:11 ` Arnd Bergmann 2021-07-26 14:11 ` [PATCH v5 06/10] ARM: oabi-compat: rework sys_semtimedop emulation Arnd Bergmann 2021-07-26 14:11 ` Arnd Bergmann 2021-07-26 14:11 ` [PATCH v5 07/10] ARM: oabi-compat: rework fcntl64() emulation Arnd Bergmann 2021-07-26 14:11 ` Arnd Bergmann 2021-07-26 14:11 ` [PATCH v5 08/10] ARM: uaccess: add __{get,put}_kernel_nofault Arnd Bergmann 2021-07-26 14:11 ` Arnd Bergmann 2022-01-12 17:29 ` Daniel Thompson 2022-01-12 17:29 ` Daniel Thompson 2022-01-12 18:08 ` Russell King (Oracle) 2022-01-12 18:08 ` Russell King (Oracle) 2022-01-13 9:47 ` Daniel Thompson 2022-01-13 9:47 ` Daniel Thompson 2022-01-13 11:14 ` Arnd Bergmann [this message] 2022-01-13 11:14 ` Arnd Bergmann 2022-02-01 17:29 ` Daniel Thompson 2022-02-01 17:29 ` Daniel Thompson 2021-07-26 14:11 ` [PATCH v5 09/10] ARM: uaccess: remove set_fs() implementation Arnd Bergmann 2021-07-26 14:11 ` Arnd Bergmann 2021-07-26 14:11 ` [PATCH v5 10/10] ARM: oabi-compat: fix oabi epoll sparse warning Arnd Bergmann 2021-07-26 14:11 ` Arnd Bergmann 2021-08-11 6:39 ` [PATCH v5 00/10] ARM: remove set_fs callers and implementation Christoph Hellwig 2021-08-11 6:39 ` Christoph Hellwig 2021-08-11 7:31 ` Arnd Bergmann 2021-08-11 7:31 ` Arnd Bergmann 2021-08-11 7:31 ` Arnd Bergmann 2022-07-05 13:07 [PATCH v5 08/10] ARM: uaccess: add __{get,put}_kernel_nofault Chen Zhongjin
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CAK8P3a0=OkFcKbL+utDPTPf+RskFNdR8Vt-3BEWkO9g_FqSj5w@mail.gmail.com' \ --to=arnd@kernel.org \ --cc=arnd@arndb.de \ --cc=daniel.thompson@linaro.org \ --cc=linus.walleij@linaro.org \ --cc=linux-arch@vger.kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=linux@armlinux.org.uk \ --cc=viro@zeniv.linux.org.uk \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.