All of lore.kernel.org
 help / color / mirror / Atom feed
From: Masami Hiramatsu <mhiramat@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Steven Rostedt <rostedt@goodmis.org>,
	Andy Lutomirski <luto@amacapital.net>,
	Linux List Kernel Mailing <linux-kernel@vger.kernel.org>,
	Ingo Molnar <mingo@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	stable <stable@vger.kernel.org>,
	Changbin Du <changbin.du@gmail.com>, Jann Horn <jannh@google.com>,
	Kees Cook <keescook@chromium.org>,
	Andy Lutomirski <luto@kernel.org>
Subject: Re: [PATCH 1/2 v2] kprobe: Do not use uaccess functions to access kernel memory that can fault
Date: Sat, 23 Feb 2019 12:47:46 +0900	[thread overview]
Message-ID: <20190223124746.d021973004c7c892c3b3fde1@kernel.org> (raw)
In-Reply-To: <CAHk-=whNf_n1WXWW+ugAVeL5ZK0GcEP3cTYocju1nS85VtMjjQ@mail.gmail.com>

On Fri, 22 Feb 2019 09:43:14 -0800
Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Fri, Feb 22, 2019 at 12:35 AM Masami Hiramatsu <mhiramat@kernel.org> wrote:
> >
> > Or, can we do this?
> >
> > long __probe_user_read(void *dst, const void *src, size_t size)
> > {
> 
> Add a
> 
>         if (!access_ok(src, size))
>                 ret = -EFAULT;
>         else {
> .. do the pagefault_disable() etc ..
>         }

Since kprobes handler runs in IRQ context, we can not use access_ok() in it.
(only on x86 + CONFIG_DEBUG_ATOMIC_SLEEP=y)

In arch/x86/include/asm/uaccess.h:

#define access_ok(addr, size)                                   \
({                                                                      \
        WARN_ON_IN_IRQ();                                               \
        likely(!__range_not_ok(addr, size, user_addr_max()));           \
})

Do we need acccess_ok_inatomic()?

BTW, it seems a bit strange that this WARN_ON_IN_IRQ() is only in x86
access_ok() implementation, since CONFIG_DEBUG_ATOMIC_SLEEP(which defines
WARN_ON_IN_IRQ) doesn't depend on x86, and access_ok() is widely used
in kernel. I think it would be better that each arch provides __access_ok()
and include/linux/uaccess.h provides access_ok() with WARN_ON_IN_IRQ().


> to after the "set_fs()", and it looks good to me. Make it clear that
> yes, this works _only_ for user reads.
> 
> Adn that makes all the games with "kernel_uaccess_faults_ok"
> pointless, so you can just remove them.

OK.

> 
> (note that the "access_ok()" has to come after we've done "set_fs()",
> because it takes the address limit from that).
> 
> Also, since normally we'd expect that we already have USER_DS, it
> might be worthwhile to do this with a wrapper, something along the
> lines of
> 
>         mm_segment_t old_fs = get_fs();
> 
>         if (segment_eq(old_fs, USER_DS))
>               return __normal_probe_user_read();
>         set_fs(USER_DS);
>         ret = __normal_probe_user_read();
>         set_fs(old_fs);
>         return ret;
> 
> and have that __normal_probe_user_read() just do
> 
>         if (!access_ok(src, size))
>                 return -EFAULT;
>         pagefault_disable();
>         ret = __copy_from_user_inatomic(dst, ...);
>         pagefault_enable();
>         return ret ? -EFAULT : 0;
> 
> which looks more obvious.

OK.

> 
> Also, I would suggest that you just make the argument type be "const
> void __user *", since the whole point is that this takes a user
> pointer, and nothing else.

Ah, right.

> Then we should still probably fix up "__probe_kernel_read()" to not
> allow user accesses. The easiest way to do that is actually likely to
> use the "unsafe_get_user()" functions *without* doing a
> uaccess_begin(), which will mean that modern CPU's will simply fault
> on a kernel access to user space.

Or, use __chk_user_ptr(ptr) to check it?

Thank you,

> 
> The nice thing about that is that usually developers will have access
> to exactly those modern boxes, so the people who notice that it
> doesn't work are the right people.
> 
> Alternatively, we should just make it be architecture-specific, so
> that architectures can decide "this address cannot be a kernel
> address" and refuse to do it.
> 
>                 Linus


-- 
Masami Hiramatsu <mhiramat@kernel.org>

  parent reply	other threads:[~2019-02-23  3:47 UTC|newest]

Thread overview: 85+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-15 17:47 [PATCH 0/2 v2] [GIT PULL (take two)] tracing: Two more fixes Steven Rostedt
2019-02-15 17:47 ` [PATCH 1/2 v2] kprobe: Do not use uaccess functions to access kernel memory that can fault Steven Rostedt
2019-02-15 17:55   ` Linus Torvalds
2019-02-15 22:15     ` Steven Rostedt
2019-02-15 23:49       ` Andy Lutomirski
2019-02-16  0:19         ` Steven Rostedt
2019-02-16  1:32           ` Andy Lutomirski
2019-02-16  2:08             ` Steven Rostedt
2019-02-16  2:14               ` Andy Lutomirski
2019-02-16  2:21                 ` Steven Rostedt
2019-02-18 17:58           ` Linus Torvalds
2019-02-18 18:23             ` Linus Torvalds
2019-02-19 16:18               ` Steven Rostedt
2019-02-19 18:43                 ` Linus Torvalds
2019-02-19 19:03                   ` Steven Rostedt
2019-02-20  8:10                     ` Masami Hiramatsu
2019-02-20 13:57                       ` Jann Horn
2019-02-20 14:47                         ` Steven Rostedt
2019-02-20 15:08                         ` Masami Hiramatsu
2019-02-20 14:49                       ` Steven Rostedt
2019-02-20 16:04                         ` Masami Hiramatsu
2019-02-20 16:42                           ` Steven Rostedt
2019-02-21  7:37                             ` Masami Hiramatsu
2019-02-22  8:27                         ` Masami Hiramatsu
2019-02-22  8:35                           ` Masami Hiramatsu
2019-02-22 17:43                             ` Linus Torvalds
2019-02-22 17:48                               ` Andy Lutomirski
2019-02-22 18:28                                 ` Linus Torvalds
2019-02-22 19:52                                   ` Andy Lutomirski
2019-02-22 19:27                               ` Alexei Starovoitov
2019-02-22 19:30                                 ` Steven Rostedt
2019-02-22 19:34                                   ` Alexei Starovoitov
2019-02-22 19:39                                     ` Steven Rostedt
2019-02-22 19:55                                     ` Andy Lutomirski
2019-02-22 21:43                                       ` Jann Horn
2019-02-22 22:08                                         ` Nadav Amit
2019-02-22 22:17                                           ` Jann Horn
2019-02-22 22:21                                             ` Nadav Amit
2019-02-22 22:39                                               ` Nadav Amit
2019-02-22 23:02                                                 ` Jann Horn
2019-02-22 23:22                                                   ` Nadav Amit
2019-02-22 23:59                                                   ` Andy Lutomirski
2019-02-23  0:03                                                     ` Alexei Starovoitov
2019-02-23  0:15                                                     ` Nadav Amit
2019-02-24 19:35                                                       ` Andy Lutomirski
2019-02-25 13:36                                                     ` Masami Hiramatsu
2019-02-22 21:20                                 ` Linus Torvalds
2019-02-22 21:38                                   ` David Miller
2019-02-22 21:59                                     ` Linus Torvalds
2019-02-22 22:51                                       ` Alexei Starovoitov
2019-02-22 23:11                                         ` Jann Horn
2019-02-22 23:16                                           ` David Miller
2019-02-22 23:16                                         ` Linus Torvalds
2019-02-22 23:56                                           ` Alexei Starovoitov
2019-02-23  0:08                                             ` Linus Torvalds
2019-02-23  2:28                                               ` Alexei Starovoitov
2019-02-23  2:32                                                 ` Linus Torvalds
2019-02-23  3:02                                                 ` Steven Rostedt
2019-02-23  4:51                                             ` Masami Hiramatsu
2019-02-26  3:57                                       ` Christoph Hellwig
2019-02-26 15:24                                 ` Joel Fernandes
2019-02-28 12:29                                   ` Masami Hiramatsu
2019-02-28 15:18                                     ` Joel Fernandes
2019-02-23  3:47                               ` Masami Hiramatsu [this message]
2019-02-24  0:44                                 ` Steven Rostedt
2019-02-24  4:38                                   ` Andy Lutomirski
2019-02-24 15:17                                     ` Masami Hiramatsu
2019-02-24 17:26                                       ` Linus Torvalds
2019-02-25  2:40                                         ` Masami Hiramatsu
2019-02-25  4:49                                           ` Andy Lutomirski
2019-02-25  8:09                                             ` Masami Hiramatsu
2019-02-25 16:40                                               ` Steven Rostedt
2019-02-26  1:35                                                 ` Masami Hiramatsu
2019-02-25  8:33                                         ` Peter Zijlstra
2019-02-25 14:52                                           ` Peter Zijlstra
2019-02-25 16:48                                     ` Kees Cook
2019-02-25 16:58                                       ` Andy Lutomirski
2019-02-25 17:07                                         ` Kees Cook
2019-02-21  7:52   ` Masami Hiramatsu
2019-02-21 14:36     ` Steven Rostedt
2019-02-21 15:58       ` Masami Hiramatsu
2019-02-21 16:16         ` Masami Hiramatsu
2019-02-21 16:32           ` Steven Rostedt
2019-02-23 14:48     ` Masami Hiramatsu
2019-02-15 17:47 ` [PATCH 2/2 v2] tracing: Fix number of entries in trace header 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=20190223124746.d021973004c7c892c3b3fde1@kernel.org \
    --to=mhiramat@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=changbin.du@gmail.com \
    --cc=jannh@google.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=luto@kernel.org \
    --cc=mingo@kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=stable@vger.kernel.org \
    --cc=torvalds@linux-foundation.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 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.