Re: [RFC] In-kernel fuzz testing for apps

From: Laura Abbott
Date: Thu Nov 19 2015 - 12:25:58 EST


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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/