lkml.org 
[lkml]   [2015]   [Nov]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Subject[RFC] In-kernel fuzz testing for apps
Date
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.

--
OpenPGP usage is appreciated (it also helps your letter to bypass spam
filters). To email me with encryption easily, go
https://encrypt.to/0xC6FCDB11

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