[RFC PATCH 0/3] Djprobe improvement patches (Re: Dynamic djprobe)

[Masami Hiramatsu <hiramatu at sdl dot hitachi dot co dot jp>]

Hi,
Yesterday Satoshi explained the following improvement ideas.

Satoshi Oshima wrote:
> And we believe that djprobe can safely modify the code like this;
>
> step 1: making int3 bypass code using kprobe
>
> step 2: safety check;
>         make sure that all CPUs don't run on the code that will
>         be replaced with jmp instruction (also check whether stack
>         include EIP of the code which is subject to replace)
>
> step 3: (after all CPU pass safety check) replace with jmp
>         instruction without first byte. leave int 3 instruction
>         unchanged at this time (new step).
>
> step 4: i-cache flush or serializing:
>         invoke i-cache flush instruction such as CLFLASH or serialize
>         instruction such as CPUID on all CPUs (new step)
>
> step 5: (after all CPU invoke i-cache flush or serializing instruction)
>         replace int 3 instruction with first byte of jmp instruction

I attempt to solve some problems based on these improvements by the 
following series of patches.

I organized problems as below.
1) Djprobe currently works on non (or voluntary)-preemptive kernel. So, 
djprobe should be disabled when CONFIG_PREEMPT is enabled. (This was 
described in my previous mail)
2) Nested interrupts hide true executing address into current thread’s 
stack. So, we find it and check this address is in safe area. (step 2: 
safety check )
3) To avoid GPF, we should be serialize or flush i-cache on each CPU. 
(step 4: i-cache flush or serializing)

I developed 3 patches to solve these problems.

Also, I and Satoshi think there is another method:
Stop all CPUs until whole instructions are replaced instead of using bypass.
I’m developing this patch too. After developed, I will send it.

Best regards,


--
Masami HIRAMATSU
2nd Research Dept.
Hitachi, Ltd., Systems Development Laboratory
E-mail: hiramatu@sdl.hitachi.co.jp