lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 21 Mar 2019 22:46:02 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Masami Hiramatsu <mhiramat@...nel.org>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Shuah Khan <shuah@...nel.org>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        linux-kernel@...r.kernel.org,
        Andy Lutomirski <luto@...capital.net>,
        Ingo Molnar <mingo@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Changbin Du <changbin.du@...il.com>,
        Jann Horn <jannh@...gle.com>,
        Kees Cook <keescook@...omium.org>,
        Andy Lutomirski <luto@...nel.org>,
        Alexei Starovoitov <alexei.starovoitov@...il.com>,
        Nadav Amit <namit@...are.com>,
        Joel Fernandes <joel@...lfernandes.org>, yhs@...com
Subject: Re: [RFC PATCH v6 1/6] x86/uaccess: Allow access_ok() in irq
 context if pagefault_disabled

On Mon, 18 Mar 2019 15:43:17 +0900
Masami Hiramatsu <mhiramat@...nel.org> wrote:

> WARN_ON_IN_IRQ() assumes that the access_ok() and following
> user memory access can sleep. But this assumption is not
> always correct; when the pagefault is disabled, following
> memory access will just returns -EFAULT and never sleep.
> 
> Add pagefault_disabled() check in WARN_ON_ONCE() so that
> it can ignore the case we call it with disabling pagefault.
> For this purpose, this modified pagefault_disabled() as
> an inline function.
> 

Actually, accessing user space from an interrupt doesn't really make
sense. Now I'm differentiating a true interrupt (like a device handler)
from an exception. The difference is that an exception is synchronous
with the execution of the code, but an interrupt is something where you
don't know what task is running. A uaccess in this type of interrupt
will randomly grab some user space memory but have no idea what task is
running.

The one time this makes sense is if you are doing some kind of
profiling, where the randomness is fine.

I'm curious, what interrupt handler are kprobes executing in that needs
random user space addresses?

-- Steve

Powered by blists - more mailing lists