[PATCH] POC for fault injection

[haris iqbal]

On Wed, Mar 23, 2016 at 6:32 AM, Dmitry V. Levin <ldv at altlinux.org> wrote:
> On Tue, Mar 22, 2016 at 08:55:25AM +0530, haris iqbal wrote:
>> On Tue, Mar 22, 2016 at 5:56 AM, Dmitry V. Levin wrote:
>> > On Mon, Mar 21, 2016 at 10:36:03AM +0530, haris iqbal wrote:
>> >> I have sent a patch which demonstrates the Idea that I thought of for
>> >> failing system calls. It overwrites the return value of the system
>> >> call with -1 to make it fail.
>> >
>> > If you want to "fail" a syscall, it has to be done on entering,
>> > on exiting it's too late.
>>
>> Yes, I thought of the same thing. So only you would find the that in
>> the other standalone POC, I reset the important parameter of the
>> syscall also to 0 while entering, and then I put -1 in place of return
>> value while exiting.
>>
>> >
>> > Could you elaborate how would you "fail" various syscalls, please?
>>
>> By reseting the important parameters to 0.
>>
>> Some examples below.
>>
>> For instance, for the read() system call only, what I did was to reset
>> the important parameter with 0. The important parameter for read() is
>> the second parameter which would hold the bytes read, and which the
>> program would use to read the data.
>> One more thing I can do is reset the first parameter holding the fd,
>> that would also fail the system call.
>>
>> For fstat() syscall, we can change the value of the first parameter
>> (which holds the socket number) to a negative number.
>>
>> Similarly, picking the important parameter and changing it to
>> something that can fail the syscall would work for us I think.
>
> To implement this method you'd have to find out for each syscall
> the parameter to override and the value to override it with.  Besides
> that, you'd have to override return values so that error code returned
> to userspace would be plausible.

Yes. Thats why I had a function pointer in the structure in my proposal.

>
> There is another method that should be simpler to implement.  On entering
> syscall, the syscall number is changed to -1.  On exiting this modified
> syscall, the return code is changed from -ENOSYS to something plausible,
> or even configurable.

Yes, this sounds better and simpler. And I just checked this and it
works. Changing syscall number to -1 makes the kernel not find any
syscall with that number, which errors to ENOSYS (error code 38) and
fails the system call. Then later we can change the return value to
something better.

>
>
> --
> ldv
>
> ------------------------------------------------------------------------------
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140
> _______________________________________________
> Strace-devel mailing list
> Strace-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/strace-devel
>



-- 

With regards,

Md Haris Iqbal,
Placement Coordinator, MTech IT
NITK Surathkal,
Contact: +91 8861996962