lkml.org 
[lkml]   [2015]   [Nov]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC] In-kernel fuzz testing for apps
From
Date
On 11/18/2015 03:39 PM, Andrey Utkin wrote:
> Me and my friend have once talked about careful application development,
> which includes awareness about all possible error conditions.
> So we have collected ideas about making kernel (or, in some cases, libc)
> "hostile" to careless application, and we present it so that the idea
> doesn't get lost, and maybe even gets real if somebody wants some
> features from the list.
>
> - (libc) crash instantly if memcpy detects regions overlapping;
> - return EINTR as much as possible;
> - send/recv/etc. returns EAGAIN on non-blocking sockets as much as possible;
> - send/recv tend to result in short writes/reads, e.g. 1 byte at a time,
> to break assumption about sending/receiving some "not-so-big" thing at once;
> - let write return ENOSPC sometimes;
> - scheduler behaves differently from common case (e.g. let it tend to
> stop a thread at some syscalls);
> - return allocation failures;
> - make OOM killer manic!
> - make clocks which are not monotonic to go backward frequently;
> - pretend the time is 2038 year or later;
> - (arguable) close syscall returns non-zero first time, or randomly;
> - (arguable) special arch having NULL not all zero-bits. Actually I
> don't believe it is feasible to make a lot of modern software to run in
> such situation.
>
> These horrific modes should be enabled per-process or per-executable-file.
>
> Thanks for your time and for any kind comment.
>

Check out CONFIG_FAULT_INJECTION, lib/fault_inject.c . There are a few things
there already. You could expand on that for other functionality.

Thanks,
Laura


\
 
 \ /
  Last update: 2015-11-19 18:41    [W:0.064 / U:0.316 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site