[Fault-injection-developer] RFC: Interceptor for PIO

[Wang, S. <sta...@in...>]

Hi, folks
I would like to build PIO interceptor on a base of Kprobes.
There are two methods that could be used : Kprobes or Kwatch.
And I would like to implement two PIO interceptor, one based on
Kwatch and another based on Kprobes. I'll illustrate the workflow
of them.

The one (whose name is "DR") based on Kwatch:
Registration/Unregistration:
           wp_register                          
core -------------------->dr_register--------------> register_kwatch

           wp_unregister                          
core -------------------->dr_unregister--------------> unregister_kwatch

Fault injection:

do_debug-------------->dr_kwatch_handler------------------>core-------------
---->injection fault

pros:
1. Kwatch's API looks pretty good and make the life easy :)

cons:
1. The number of debug register is limited (only 4). 
2. The debug exception is triggered after the watched IO port was accessed,
hence 
we couldn't do nothing about wrtie access.


The one (whose name is "DBP") based on Kprobes:
Registration/Unregistration:
           wp_register                          
core -------------------->dbp_register--------------> register_kprobe

           wp_unregister                          
core -------------------->dbp_unregister--------------> unregister_kprobe


Fault injection:
 
there is write fault
do_int3----------------->dbp_pre_kprobe_handler-------------------------->co
re-------------->(inject write fault)

do_debug------------->dbp_post_kpobe_handler-------------------------->core-
--------------
------->inject read fault or restore context for injected write fault

pros:
1. As many breakpoints as you wish :)

cons:
1. A user mode utility is needed for finding all IO related instructions
out.
2. And we need to export the symbol "modules" for locating the wanted
instructions.


Your Sincerely,
Stanley Wang 

SW Engineer, Intel Corporation.
Intel China Software Lab. 
Tel: 021-52574545 ext. 1171 
iNet: 8-752-1171 
 
Opinions expressed are those of the author and do not represent Intel
Corporation