All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Laight <David.Laight@ACULAB.COM>
To: 'Daniel Borkmann' <daniel@iogearbox.net>,
	Al Viro <viro@zeniv.linux.org.uk>
Cc: Christoph Hellwig <hch@lst.de>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	the arch/x86 maintainers <x86@kernel.org>,
	Alexei Starovoitov <ast@kernel.org>,
	Masami Hiramatsu <mhiramat@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	"linux-parisc@vger.kernel.org" <linux-parisc@vger.kernel.org>,
	linux-um <linux-um@lists.infradead.org>,
	Netdev <netdev@vger.kernel.org>,
	"bpf@vger.kernel.org" <bpf@vger.kernel.org>,
	Linux-MM <linux-mm@kvack.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"bgregg@netflix.com" <bgregg@netflix.com>
Subject: RE: [PATCH 11/18] maccess: remove strncpy_from_unsafe
Date: Thu, 14 May 2020 10:01:45 +0000	[thread overview]
Message-ID: <6ca8d8499bf644aba0b242d194df5a60@AcuMS.aculab.com> (raw)
In-Reply-To: <866cbe54-a027-04eb-65db-c6423d16b924@iogearbox.net>

From: Daniel Borkmann
> Sent: 14 May 2020 00:59
> On 5/14/20 1:28 AM, Al Viro wrote:
> > On Thu, May 14, 2020 at 12:36:28AM +0200, Daniel Borkmann wrote:
> >
> >>> 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.
> >>
> >> It's used for both. Given this is enabled on pretty much all program types, my
> >> assumption would be that usage is still more often on kernel memory than user one.
> >
> > Then it needs an argument telling it which one to use.  Look at sparc64.
> > Or s390.  Or parisc.  Et sodding cetera.
> >
> > The underlying model is that the kernel lives in a separate address space.
> > Yes, on x86 it's actually sharing the page tables with userland, but that's
> > not universal.  The same address can be both a valid userland one _and_
> > a valid kernel one.  You need to tell which one do you want.
> 
> Yes, see also 6ae08ae3dea2 ("bpf: Add probe_read_{user, kernel} and probe_read_{user,
> kernel}_str helpers"), and my other reply wrt bpf_trace_printk() on how to address
> this. All I'm trying to say is that both bpf_probe_read() and bpf_trace_printk() do
> exist in this form since early [e]bpf days for ~5yrs now and while broken on non-x86
> there are a lot of users on x86 for this in the wild, so they need to have a chance
> to migrate over to the new facilities before they are fully removed.

If it's not a stupid question why is a BPF program allowed to get
into a situation where it might have an invalid kernel address.

It all stinks of a hole that allows all of kernel memory to be read
and copied to userspace.

Now you might want to something special so that BPF programs just
abort on OOPS instead of possibly paniking the kernel.
But that is different from a copy that expects to be passed garbage.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

  reply	other threads:[~2020-05-14 10:01 UTC|newest]

Thread overview: 54+ 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 ` [PATCH 01/18] maccess: unexport probe_kernel_write and probe_user_write Christoph Hellwig
2020-05-13 16:00 ` [PATCH 02/18] maccess: remove various unused weak aliases Christoph Hellwig
2020-05-13 16:00 ` [PATCH 03/18] maccess: remove duplicate kerneldoc comments Christoph Hellwig
2020-05-13 16:00 ` [PATCH 04/18] maccess: clarify " Christoph Hellwig
2020-05-13 16:00 ` [PATCH 05/18] maccess: update the top of file comment 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 ` [PATCH 07/18] maccess: rename strncpy_from_unsafe_strict to strncpy_from_kernel_nofault 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 ` [PATCH 09/18] maccess: remove probe_read_common and probe_write_common Christoph Hellwig
2020-05-13 16:00 ` [PATCH 10/18] maccess: unify the probe kernel arch hooks Christoph Hellwig
2020-05-14  1:13   ` Masami Hiramatsu
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 19:11   ` Linus Torvalds
2020-05-13 19:11     ` Linus Torvalds
2020-05-13 19:28     ` Christoph Hellwig
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:24           ` Daniel Borkmann
2020-05-13 23:20         ` Masami Hiramatsu
2020-05-13 23:59           ` Linus Torvalds
2020-05-13 23:59             ` Linus Torvalds
2020-05-14  1:00             ` Masami Hiramatsu
2020-05-14  2:43               ` Linus Torvalds
2020-05-14  2:43                 ` Linus Torvalds
2020-05-14  9:44                 ` Masami Hiramatsu
2020-05-14 10:27                   ` Daniel Borkmann
2020-05-13 23:28         ` Al Viro
2020-05-13 23:58           ` Daniel Borkmann
2020-05-14 10:01             ` David Laight [this message]
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 ` [PATCH 13/18] maccess: move user access routines together Christoph Hellwig
2020-05-13 16:00 ` [PATCH 14/18] maccess: allow architectures to provide kernel probing directly Christoph Hellwig
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:48       ` Linus Torvalds
2020-05-13 19:48         ` Linus Torvalds
2020-05-13 19:54         ` Christoph Hellwig
2020-05-16  3:42   ` Masami Hiramatsu
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 ` [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 18/18] maccess: rename probe_kernel_address to get_kernel_nofault 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 23:04 ` Daniel Borkmann
2020-05-13 23:20   ` Linus Torvalds
2020-05-13 23:20     ` Linus Torvalds
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=6ca8d8499bf644aba0b242d194df5a60@AcuMS.aculab.com \
    --to=david.laight@aculab.com \
    --cc=akpm@linux-foundation.org \
    --cc=ast@kernel.org \
    --cc=bgregg@netflix.com \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=hch@lst.de \
    --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=viro@zeniv.linux.org.uk \
    --cc=x86@kernel.org \
    --subject='RE: [PATCH 11/18] maccess: remove strncpy_from_unsafe' \
    /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: link

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.