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

From: Austin S Hemmelgarn
Date: Thu Nov 19 2015 - 10:38:15 EST

On 2015-11-18 18:39, 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.
This is an excellent idea for security testing, however, see below for more thoughts.

- (libc) crash instantly if memcpy detects regions overlapping;
I believe there are actually systems out there that do this, but they are ancient by now.
- 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;
These three are tricky to do from userspace, but the first two could be done with ptrace with some effort (not sure about the third).
- let write return ENOSPC sometimes;
Ironically, this can be done without much effort using BTRFS (although that will hopefully change in the future).
- scheduler behaves differently from common case (e.g. let it tend to
stop a thread at some syscalls);
I don't see this one being very useful for any program that isn't running realtime or accessing hardware directly.
- return allocation failures;
I'm pretty certain there is some library out there that you can preload to do this.
- make OOM killer manic!
This isn't hard to do in a VM, either randomly adjust the memory balloon, or randomly enter the scan-code for Ctrl-Alt-SysRq-F on the console.
- make clocks which are not monotonic to go backward frequently;
Same as above, but for different reasons.
- pretend the time is 2038 year or later;
Same as above, also look up a program called 'datefudge'.
- (arguable) close syscall returns non-zero first time, or randomly;
I'm actually genuinely curious about this one. What real-world circumstances could cause close() to fail?
- (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.
This one is a functional guarantee for almost anything that uses virtual memory. In theory, it might be possible to get a lot of things working with NULL = 0xFFFFFFFF (or the equivalent on 64-bit arches), but I don't see that being particularly useful (anything that does anything with NULL other than check against it and use it as a dummy initializer is probably broken in other ways).

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature