From: Linus Torvalds <torvalds@linux-foundation.org>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Linux List Kernel Mailing <linux-kernel@vger.kernel.org>,
Ingo Molnar <mingo@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH 0/2] [GIT PULL] tracing: Two more fixes
Date: Fri, 15 Feb 2019 09:08:38 -0800 [thread overview]
Message-ID: <CAHk-=wj9vT-Wma+1tT2OA7om2UVavydPv6EsPNOT658sE0Z6=g@mail.gmail.com> (raw)
In-Reply-To: <20190215142015.860423791@goodmis.org>
On Fri, Feb 15, 2019 at 6:21 AM Steven Rostedt <rostedt@goodmis.org> wrote:
>
> - Have kprobes not use copy_from_user to access kernel addresses
> as this is now considered a security issue.
No, you people are confused.
The problem isn't that it's using a user access function on kernel memory.
The problem is that it's using a user access function on a complete
garbage pointer that happens to not even be a valid pointer at all.
You get a GP fault because the code tries to access an address at
0x2e646c2f6374652f.
That's not a valid pointer on x86-64. Nothing to do with user or
kernel, everything to do with "it's garbage".
Switching over to probe_mem_read() just means that even non-canonical
address faults are ignored. But it has absolutely nothing to do with
"kernel addresses" or any security issues.
So the patch looks like it might be ok, but the explanations for it
are garbage and only confuse the issue.
Please fix the explanations, I don't want to have actively wrong
commit messages for when people start looking at things like this.
Linus
next prev parent reply other threads:[~2019-02-15 17:09 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-15 14:20 [PATCH 0/2] [GIT PULL] tracing: Two more fixes Steven Rostedt
2019-02-15 14:20 ` [PATCH 1/2] kprobe: Do not use uaccess functions to access kernel memory Steven Rostedt
2019-02-15 14:20 ` [PATCH 2/2] tracing: Fix number of entries in trace header Steven Rostedt
2019-02-15 17:08 ` Linus Torvalds [this message]
2019-02-15 17:22 ` [PATCH 0/2] [GIT PULL] tracing: Two more fixes Steven Rostedt
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='CAHk-=wj9vT-Wma+1tT2OA7om2UVavydPv6EsPNOT658sE0Z6=g@mail.gmail.com' \
--to=torvalds@linux-foundation.org \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=rostedt@goodmis.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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).