Re: Notes from the systemtap BOF

[Mathieu Desnoyers <compudj at krystal dot dyndns dot org>]

* Masami Hiramatsu (hiramatu@sdl.hitachi.co.jp) wrote:
> If CPU B stacks the EIP, then yes it cause invalid instruction error.
> But before insertion, djprobe has checked whether the all CPUs are through
> the djprobe's kprobe bypass.
> There is a hazard situation that an interrupt handler calls a recursive 
> function that interrupted by that interrupt handler.
> I think, we should check the EIP in the entry of interrupt handler.
> 

When do you decide when you start to check the EIP on the interrupt handler
stack ? If we think about the preemption case, any kernel thread could be
scheduled out by an interrupt and only going back far later.

For my understanding, your proposal is to add a dynamic probe to interrupt
handlers prior to add this jmp, checking that no interrupt is having the return 
address equals to one you which to modify. The fact is, in the preemption case,
that this EIP could have been saved to memory a long time before you decide to
put an interrupt instruction there.

Not putting an instrumentation at kernel start time leaves an uncertainty about
the other processes stacks.

> >I think that the interrupt protection does not guarantee that no CPU has 
> >this
> >EIP address on their stack or in their current EIP : it only protects from 
> >CPU
> >which has not gone in this code path yet.
> >
> >But maybe am I wrong ?
> 
> No, you are right. I do not use the interrupt protection.
> 

Even if you did disable interrupts around the assembly code you modifiy, there
would still be the shadow of NMIs around.


> If that, djprobe can not replace the breakpoint to jump instruction. And 
> djprobe consumes the overhead same as kprobe in that situation.
> I think if the EIP is checked in the interrupt handler, we can insert 
> jmp code.
> Currently, I think the entry of most functions are safe areas. Because 
> the functions just save the registers and expand local stacks.
> 

Knowing what code pattern follows greatly helps knowing if the instructions are
relocatable.

> Or, should we consider the idea that we use the simple space that 
> contains just 5 nops(*) ?
> 

This would help being able to put a proble at difficult places in the kernel (in
the middle of a function where variables x and y are available, for instance)
without having to know the exact assembly result of the function, which I think
is a good idea.

It does not protect from an interrupt (including preemption) happening in the
middle of the nops though.

Mathieu



OpenPGP public key:              http://krystal.dyndns.org:8080/key/compudj.gpg
Key fingerprint:     8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68