[PATCH 3/4] Introduce syscall fault injection feature

[Gabriel Laskar]

On Fri, 29 Jul 2016 04:04:02 +0300
"Dmitry V. Levin" <ldv at altlinux.org> wrote:

> On Wed, Jul 27, 2016 at 08:41:16PM +0200, Nahim El Atmani wrote:
> > From: Nahim El Atmani <naam at lse.epita.fr>
> > 
> > From: Nahim El Atmani <nahim+dev at naam.me>
> > 
> > * defs.h: Add new qualifier and struct fault_opts
> > * linux/x86_64/fault.h: New file.
> >   (fault_set_sc_err): New function.
> >   (fault_discard_sc): Likewise.
> > * Makefile.am: Add it.
> > * syscall.c (reallocate_fault): New function.
> >   (qualify_one): Also extend the size of faults_vec.
> >   (qual_fault): New function.
> >   (qual_signal): Also reallocate faults_vec.
> >   (fault_syscall_enter): New function.
> >   (fault_syscall_exit): Likewise.
> >   (trace_syscall_entering): Discard syscall if needed.
> >   (trace_syscall_exiting): Set syscall's return error value, print
> > when syscall has been discarded.
> > 
> > Signed-off-by: Nahim El Atmani <nahim+dev at naam.me>
> > Reviewed-By: Gabriel Laskar <gabriel at lse.epita.fr>
> > ---
> > * The fault injection is currently only available for i386 &
> > x86_64, hence a  
> 
> Why the fault injection is limited to i386 and x86_64?
> The mechanism of setting syscall number and error code is similar on
> all architectures.
> 
> >   new configure flag have been created (--enable-fault-injection)
> > to keep the build clean on other architectures.  
> 
> Please don't make this option configurable.  It complicates the code
> (== causes mistakes) and gives very little in return.


The goal here was to enable the feature only for architecture where
this was really tested, mainly in order to validate the model, and
after, enable it without an option, when properly tested on all
architectures.

> 
> > * Concerning the struct qual_options, the name 'fault' and short
> > name 'f' are not fixed, feel free to comment if something better
> > comes to your mind.
> > * Regarding the error number checks in qual_fault(), they're light
> > on purpose to allow one to return any kind of return value.  
> 
> Even if they are light, they should be correct.
> 
> > * There is still one TODO left which is supporting the fuzzy
> > approach using percentage as an occurrence. It should comes soon
> > since all the option parsing is done. On that note fuzzing means we
> > want to be able to reproduce, so we have to keep the seed somewhere
> > and take it as an input. I my opinion using the environment for
> > this kind of things is better than adding a new option, what do you
> > think?  
> 
> Using environment is OK.

Something like STRACE_SEED should be ok?



-- 
Gabriel Laskar