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 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).

[unhandled content-type:application/pkcs7-signature]
\
 
 \ /
  Last update: 2015-11-19 17:01    [W:2.992 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site