From: Christoph Hellwig <hch@lst.de> To: Linus Torvalds <torvalds@linux-foundation.org> Cc: Christoph Hellwig <hch@lst.de>, the arch/x86 maintainers <x86@kernel.org>, Alexei Starovoitov <ast@kernel.org>, Daniel Borkmann <daniel@iogearbox.net>, Masami Hiramatsu <mhiramat@kernel.org>, Andrew Morton <akpm@linux-foundation.org>, linux-parisc@vger.kernel.org, linux-um <linux-um@lists.infradead.org>, Netdev <netdev@vger.kernel.org>, bpf@vger.kernel.org, Linux-MM <linux-mm@kvack.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org> Subject: Re: [PATCH 11/18] maccess: remove strncpy_from_unsafe Date: Wed, 13 May 2020 21:28:04 +0200 [thread overview] Message-ID: <20200513192804.GA30751@lst.de> (raw) In-Reply-To: <CAHk-=wj=u+nttmd1huNES2U=9nePtmk7WgR8cMLCYS8wc=rhdA@mail.gmail.com> On Wed, May 13, 2020 at 12:11:27PM -0700, Linus Torvalds wrote: > On Wed, May 13, 2020 at 9:01 AM Christoph Hellwig <hch@lst.de> wrote: > > > > +static void bpf_strncpy(char *buf, long unsafe_addr) > > +{ > > + buf[0] = 0; > > + if (strncpy_from_kernel_nofault(buf, (void *)unsafe_addr, > > + BPF_STRNCPY_LEN)) > > + strncpy_from_user_nofault(buf, (void __user *)unsafe_addr, > > + BPF_STRNCPY_LEN); > > +} > > This seems buggy when I look at it. > > It seems to think that strncpy_from_kernel_nofault() returns an error code. > > Not so, unless I missed where you changed the rules. I didn't change the rules, so yes, this is wrong. > Also, I do wonder if we shouldn't gate this on TASK_SIZE, and do the > user trial first. On architectures where this thing is valid in the > first place (ie kernel and user addresses are separate), the test for > address size would allow us to avoid a pointless fault due to an > invalid kernel access to user space. > > So I think this function should look something like > > static void bpf_strncpy(char *buf, long unsafe_addr) > { > /* Try user address */ > if (unsafe_addr < TASK_SIZE) { > void __user *ptr = (void __user *)unsafe_addr; > if (strncpy_from_user_nofault(buf, ptr, BPF_STRNCPY_LEN) >= 0) > return; > } > > /* .. fall back on trying kernel access */ > buf[0] = 0; > strncpy_from_kernel_nofault(buf, (void *)unsafe_addr, > BPF_STRNCPY_LEN); > } > > or similar. No? So on say s390 TASK_SIZE_USUALLy is (-PAGE_SIZE), which means we'd alway try the user copy first, which seems odd. I'd really like to here from the bpf folks what the expected use case is here, and if the typical argument is kernel or user memory.
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@lst.de> To: Linus Torvalds <torvalds@linux-foundation.org> Cc: linux-parisc@vger.kernel.org, Daniel Borkmann <daniel@iogearbox.net>, Netdev <netdev@vger.kernel.org>, the arch/x86 maintainers <x86@kernel.org>, linux-um <linux-um@lists.infradead.org>, Alexei Starovoitov <ast@kernel.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Linux-MM <linux-mm@kvack.org>, bpf@vger.kernel.org, Masami Hiramatsu <mhiramat@kernel.org>, Andrew Morton <akpm@linux-foundation.org>, Christoph Hellwig <hch@lst.de> Subject: Re: [PATCH 11/18] maccess: remove strncpy_from_unsafe Date: Wed, 13 May 2020 21:28:04 +0200 [thread overview] Message-ID: <20200513192804.GA30751@lst.de> (raw) In-Reply-To: <CAHk-=wj=u+nttmd1huNES2U=9nePtmk7WgR8cMLCYS8wc=rhdA@mail.gmail.com> On Wed, May 13, 2020 at 12:11:27PM -0700, Linus Torvalds wrote: > On Wed, May 13, 2020 at 9:01 AM Christoph Hellwig <hch@lst.de> wrote: > > > > +static void bpf_strncpy(char *buf, long unsafe_addr) > > +{ > > + buf[0] = 0; > > + if (strncpy_from_kernel_nofault(buf, (void *)unsafe_addr, > > + BPF_STRNCPY_LEN)) > > + strncpy_from_user_nofault(buf, (void __user *)unsafe_addr, > > + BPF_STRNCPY_LEN); > > +} > > This seems buggy when I look at it. > > It seems to think that strncpy_from_kernel_nofault() returns an error code. > > Not so, unless I missed where you changed the rules. I didn't change the rules, so yes, this is wrong. > Also, I do wonder if we shouldn't gate this on TASK_SIZE, and do the > user trial first. On architectures where this thing is valid in the > first place (ie kernel and user addresses are separate), the test for > address size would allow us to avoid a pointless fault due to an > invalid kernel access to user space. > > So I think this function should look something like > > static void bpf_strncpy(char *buf, long unsafe_addr) > { > /* Try user address */ > if (unsafe_addr < TASK_SIZE) { > void __user *ptr = (void __user *)unsafe_addr; > if (strncpy_from_user_nofault(buf, ptr, BPF_STRNCPY_LEN) >= 0) > return; > } > > /* .. fall back on trying kernel access */ > buf[0] = 0; > strncpy_from_kernel_nofault(buf, (void *)unsafe_addr, > BPF_STRNCPY_LEN); > } > > or similar. No? So on say s390 TASK_SIZE_USUALLy is (-PAGE_SIZE), which means we'd alway try the user copy first, which seems odd. I'd really like to here from the bpf folks what the expected use case is here, and if the typical argument is kernel or user memory. _______________________________________________ linux-um mailing list linux-um@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-um
next prev parent reply other threads:[~2020-05-13 19:28 UTC|newest] Thread overview: 100+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-05-13 16:00 clean up and streamline probe_kernel_* and friends v2 Christoph Hellwig 2020-05-13 16:00 ` Christoph Hellwig 2020-05-13 16:00 ` [PATCH 01/18] maccess: unexport probe_kernel_write and probe_user_write Christoph Hellwig 2020-05-13 16:00 ` Christoph Hellwig 2020-05-13 16:00 ` [PATCH 02/18] maccess: remove various unused weak aliases Christoph Hellwig 2020-05-13 16:00 ` Christoph Hellwig 2020-05-13 16:00 ` [PATCH 03/18] maccess: remove duplicate kerneldoc comments Christoph Hellwig 2020-05-13 16:00 ` Christoph Hellwig 2020-05-13 16:00 ` [PATCH 04/18] maccess: clarify " Christoph Hellwig 2020-05-13 16:00 ` Christoph Hellwig 2020-05-13 16:00 ` [PATCH 05/18] maccess: update the top of file comment Christoph Hellwig 2020-05-13 16:00 ` Christoph Hellwig 2020-05-13 16:00 ` [PATCH 06/18] maccess: rename strncpy_from_unsafe_user to strncpy_from_user_nofault Christoph Hellwig 2020-05-13 16:00 ` Christoph Hellwig 2020-05-13 16:00 ` [PATCH 07/18] maccess: rename strncpy_from_unsafe_strict to strncpy_from_kernel_nofault Christoph Hellwig 2020-05-13 16:00 ` Christoph Hellwig 2020-05-13 16:00 ` [PATCH 08/18] maccess: rename strnlen_unsafe_user to strnlen_user_nofault Christoph Hellwig 2020-05-13 16:00 ` Christoph Hellwig 2020-05-13 16:00 ` [PATCH 09/18] maccess: remove probe_read_common and probe_write_common Christoph Hellwig 2020-05-13 16:00 ` Christoph Hellwig 2020-05-13 16:00 ` [PATCH 10/18] maccess: unify the probe kernel arch hooks Christoph Hellwig 2020-05-13 16:00 ` Christoph Hellwig 2020-05-14 1:13 ` Masami Hiramatsu 2020-05-14 1:13 ` Masami Hiramatsu 2020-05-19 5:46 ` Christoph Hellwig 2020-05-19 5:46 ` Christoph Hellwig 2020-05-13 16:00 ` [PATCH 11/18] maccess: remove strncpy_from_unsafe Christoph Hellwig 2020-05-13 16:00 ` Christoph Hellwig 2020-05-13 19:11 ` Linus Torvalds 2020-05-13 19:11 ` Linus Torvalds 2020-05-13 19:11 ` Linus Torvalds 2020-05-13 19:28 ` Christoph Hellwig [this message] 2020-05-13 19:28 ` Christoph Hellwig 2020-05-13 22:36 ` Daniel Borkmann 2020-05-13 22:36 ` Daniel Borkmann 2020-05-13 23:03 ` Linus Torvalds 2020-05-13 23:03 ` Linus Torvalds 2020-05-13 23:03 ` Linus Torvalds 2020-05-13 23:24 ` Daniel Borkmann 2020-05-13 23:24 ` Daniel Borkmann 2020-05-13 23:20 ` Masami Hiramatsu 2020-05-13 23:20 ` Masami Hiramatsu 2020-05-13 23:59 ` Linus Torvalds 2020-05-13 23:59 ` Linus Torvalds 2020-05-13 23:59 ` Linus Torvalds 2020-05-14 1:00 ` Masami Hiramatsu 2020-05-14 1:00 ` Masami Hiramatsu 2020-05-14 2:43 ` Linus Torvalds 2020-05-14 2:43 ` Linus Torvalds 2020-05-14 2:43 ` Linus Torvalds 2020-05-14 9:44 ` Masami Hiramatsu 2020-05-14 9:44 ` Masami Hiramatsu 2020-05-14 10:27 ` Daniel Borkmann 2020-05-14 10:27 ` Daniel Borkmann 2020-05-13 23:28 ` Al Viro 2020-05-13 23:28 ` Al Viro 2020-05-13 23:58 ` Daniel Borkmann 2020-05-13 23:58 ` Daniel Borkmann 2020-05-14 10:01 ` David Laight 2020-05-14 10:01 ` David Laight 2020-05-14 10:21 ` Daniel Borkmann 2020-05-14 10:21 ` Daniel Borkmann 2020-05-13 16:00 ` [PATCH 12/18] maccess: always use strict semantics for probe_kernel_read Christoph Hellwig 2020-05-13 16:00 ` Christoph Hellwig 2020-05-13 16:00 ` [PATCH 13/18] maccess: move user access routines together Christoph Hellwig 2020-05-13 16:00 ` Christoph Hellwig 2020-05-13 16:00 ` [PATCH 14/18] maccess: allow architectures to provide kernel probing directly Christoph Hellwig 2020-05-13 16:00 ` Christoph Hellwig 2020-05-13 19:36 ` Linus Torvalds 2020-05-13 19:36 ` Linus Torvalds 2020-05-13 19:36 ` Linus Torvalds 2020-05-13 19:40 ` Christoph Hellwig 2020-05-13 19:40 ` Christoph Hellwig 2020-05-13 19:48 ` Linus Torvalds 2020-05-13 19:48 ` Linus Torvalds 2020-05-13 19:48 ` Linus Torvalds 2020-05-13 19:54 ` Christoph Hellwig 2020-05-13 19:54 ` Christoph Hellwig 2020-05-16 3:42 ` Masami Hiramatsu 2020-05-16 3:42 ` Masami Hiramatsu 2020-05-18 15:09 ` Christoph Hellwig 2020-05-18 15:09 ` Christoph Hellwig 2020-05-13 16:00 ` [PATCH 15/18] x86: use non-set_fs based maccess routines Christoph Hellwig 2020-05-13 16:00 ` Christoph Hellwig 2020-05-13 16:00 ` [PATCH 16/18] maccess: rename probe_kernel_{read,write} to copy_{from,to}_kernel_nofault Christoph Hellwig 2020-05-13 16:00 ` [PATCH 16/18] maccess: rename probe_kernel_{read, write} to copy_{from, to}_kernel_nofault Christoph Hellwig 2020-05-13 16:00 ` [PATCH 17/18] maccess: rename probe_user_{read,write} to copy_{from,to}_user_nofault Christoph Hellwig 2020-05-13 16:00 ` [PATCH 17/18] maccess: rename probe_user_{read, write} to copy_{from, to}_user_nofault Christoph Hellwig 2020-05-13 16:00 ` [PATCH 18/18] maccess: rename probe_kernel_address to get_kernel_nofault Christoph Hellwig 2020-05-13 16:00 ` Christoph Hellwig 2020-05-13 19:37 ` clean up and streamline probe_kernel_* and friends v2 Linus Torvalds 2020-05-13 19:37 ` Linus Torvalds 2020-05-13 19:37 ` Linus Torvalds 2020-05-13 23:04 ` Daniel Borkmann 2020-05-13 23:04 ` Daniel Borkmann 2020-05-13 23:20 ` Linus Torvalds 2020-05-13 23:20 ` Linus Torvalds 2020-05-13 23:20 ` Linus Torvalds 2020-05-19 5:50 ` Christoph Hellwig 2020-05-19 5:50 ` Christoph Hellwig
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=20200513192804.GA30751@lst.de \ --to=hch@lst.de \ --cc=akpm@linux-foundation.org \ --cc=ast@kernel.org \ --cc=bpf@vger.kernel.org \ --cc=daniel@iogearbox.net \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=linux-parisc@vger.kernel.org \ --cc=linux-um@lists.infradead.org \ --cc=mhiramat@kernel.org \ --cc=netdev@vger.kernel.org \ --cc=torvalds@linux-foundation.org \ --cc=x86@kernel.org \ /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.