[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20151204080044.GH14427@amd>
Date: Fri, 4 Dec 2015 09:00:45 +0100
From: Pavel Machek <pavel@....cz>
To: Andrey Utkin <andrey.od.utkin@...il.com>
Cc: linux-kernel@...r.kernel.org, Anton <anton@...apica.im>
Subject: Re: [RFC] In-kernel fuzz testing for apps
Hi!
> 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.
Most of these should be doable with ptrace. You could use for example
subterfugue as a base.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists