lkml.org 
[lkml]   [2016]   [Mar]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v11 3/9] arm64: add copy_to/from_user to kprobes blacklist
Hi James,

On 18/03/2016:02:02:49 PM, James Morse wrote:
> Hi Pratyush,
>
> On 18/03/16 13:29, Pratyush Anand wrote:
> > Probably, I can see why does not it work. So, when we are single stepping an
> > instruction and page fault occurs, we will come to el1_da in entry.S. Here, we
> > do enable_dbg. As soon as we will do this, we will start receiving single step
> > exception after each instruction (not sure, probably for each alternate
> > instruction). Since, there will not be any matching single step handler for
> > these instructions, so we will see warning "Unexpected kernel single-step
> > exception at EL1".
> >
> > So, I think, we should
> >
> > (1) may be do not enable debug for el1_da, or
> > (2) enable_dbg only when single stepping is not enabled, or
> > (3) or disable single stepping during el1_da execution.
> >
> > (1) will solve the issue for sure, but not sure if it could be the best choice.
>
> A variation on (3):
>
> In kernel/entry.S when entered from EL0 we test for TIF_SINGLESTEP in the
> thread_info flags, and use disable_step_tsk/enable_step_tsk to save/restore the
> single-step state.
>
> Could we do this regardless of which EL we came from?

Thanks for another idea. I think, we can not do this as it is, because
TIF_SINGLESTEP will not be set for kprobe events. But, we can introduce a
variant disable_step_kernel and enable_step_kernel, which can be called in
el1_da.

I will write a test case to reproduce the issue without this patch, and then
will do test with a patch based on something like above.

~Pratyush

\
 
 \ /
  Last update: 2016-03-18 16:21    [W:0.095 / U:0.164 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site