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

[Austin S Hemmelgarn <ahferroin7@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2736 bytes --]

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 #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]