From: Andrey Utkin <andrey.od.utkin@gmail.com>
To: linux-kernel@vger.kernel.org, Anton <anton@picapica.im>
Subject: [RFC] In-kernel fuzz testing for apps
Date: Thu, 19 Nov 2015 01:39:28 +0200 [thread overview]
Message-ID: <564D0C30.8010009@gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 1536 bytes --]
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
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
next reply other threads:[~2015-11-18 23:39 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-18 23:39 Andrey Utkin [this message]
2015-11-19 15:37 ` [RFC] In-kernel fuzz testing for apps Austin S Hemmelgarn
2015-11-19 17:25 ` Laura Abbott
2015-12-04 8:00 ` Pavel Machek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=564D0C30.8010009@gmail.com \
--to=andrey.od.utkin@gmail.com \
--cc=anton@picapica.im \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.