[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190219111802.1d6dbaa3@gandalf.local.home>
Date: Tue, 19 Feb 2019 11:18:02 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Andy Lutomirski <luto@...capital.net>,
Linux List Kernel Mailing <linux-kernel@...r.kernel.org>,
Ingo Molnar <mingo@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
stable <stable@...r.kernel.org>,
Changbin Du <changbin.du@...il.com>,
Jann Horn <jannh@...gle.com>,
Kees Cook <keescook@...omium.org>,
Andy Lutomirski <luto@...nel.org>,
Masami Hiramatsu <mhiramat@...nel.org>
Subject: Re: [PATCH 1/2 v2] kprobe: Do not use uaccess functions to access
kernel memory that can fault
[ Added Masami too. Start of thread is here:
http://lkml.kernel.org/r/20190215174712.372898450@goodmis.org ]
On Mon, 18 Feb 2019 10:23:44 -0800
Linus Torvalds <torvalds@...ux-foundation.org> wrote:
> So it would be good to not just say "user or kernel", but actually say
> what *kind* of kernel access it expects.
Note, kprobes are a different kind of beast. I've used kprobes to probe
userspace information as well as kernel. Heck, I could see someone
even using kprobes to probe IO memory to check if a device is doing
what they expect it's doing.
Basically, a kprobe is mostly used for debugging what's happening in a
live kernel, to read any address. But for those that are more security
minded, perhaps we could add "layers" via CONFIG or /sys files that
prevent kprobes from doing certain kinds of probes?
-- Steve
Powered by blists - more mailing lists